Re: overloading malloc is impossible

[John Moser <john dot r dot moser at gmail dot com>]

On Mon, 2006-08-28 at 09:34 +0000, Wolfram Gloger wrote:
> Hi,
> 
> > I have no idea why this isn't working; but I'm trying to replace the
> > glibc allocator with something else via an LD_PRELOAD.
> 
> This should work, but it isn't easy.  Maybe try the hooks first.
> 
> > As a preliminary
> > step, I've decided to do something simple:  LD_PRELOAD something that
> > calls straight mmap() and see if it works.
> 
> You have:
> 
>  #define PAGE_ALIGN(x) (4096 + x & ~4095)
>                               ^ ^ parentheses missing

Algebraicly it's the same; but....

> ...
>  PAGE_ALIGN(size + sizeof(size_t)) // oops!

.... yeah 4096 + size + (sizeof(size_t) & ~4095) won't do :)

> 
> ...
> 
>  return addr + sizeof(size_t);
> 
> That last one returns addresses aligned at 4, unsuitable for double
> precision floats.
> 

How large are double precision floats?  80 bits?  I was wondering wtf a
TB was for (TenByte, old old 286 assembly stuff).

What do addresses have to round to?  16 bytes?  It looks like linux
rounds the stack to that on every architecture in existence.

> I didn't look much further..
> 
> > No idea why, but 'ls' works, 'find' fails, 'xclock' works, and
> > 'gcalctool' fails.  Most anything fails really.  I know the approach is
> > crude, but it's not broken.  Is there some secret trick to replacing
> > glibc's allocator?
> 
> You have to provide thread-safety for all but trivial programs.  That
> involves not only locking, but also pthread_atfork() hooks.
> 

Actually the PoC just switches it with mmap() so there should be no
thread safety issues.  I wind up with segments looking like:

[size][data...........]

so I just take ptr-sizeof(size_t) on realloc/free to get the size back.
The only thread issues are if multiple threads decide to realloc() or
free() the same data at the same time, which will break anyway.

I have a better design that does use rwlock and mutex; I don't have a
pthread_atfork() function though...

       The expected usage is that the prepare handler acquires all mutex
       locks and the other two fork handlers release them.

This means locking my entire allocator tree.  Not a problem; I'll take a
write lock on the Main Branch and lock the mutexes on each reduced
lookup array for thread branches in prepare, and then release them all
in the parent and do an orphan combine in the child.

       The order of calls to pthread_atfork() is significant. The
       parent  and child  fork  handlers  shall  be called in the order
       in which they were established by calls to pthread_atfork().
       The  prepare  fork  handlers shall be called in the opposite
       order.

Lucky, every one just adds to the list!  No worries about libraries
smashing me, so I'll just throw this in my constructor.

> Maybe take a look at "Electric Fence".  Last I checked, admittedly
> a long time ago, that worked as an LD_PRELOAD shared library.
> 

Yeah I figured this part out.  I just had to start over from scratch.

> Regards,
> Wolfram.
-- 
John Moser <john.r.moser@gmail.com>

Attachment: signature.asc
Description: This is a digitally signed message part