Re: overriding malloc
Re: overriding malloc
- Subject: Re: overriding malloc
- From: Mike Smith <email@hidden>
- Date: Fri, 15 Apr 2005 10:49:16 -0700
On Apr 14, 2005, at 12:05 PM, email@hidden wrote:
Because we need to override malloc, and the only way we can figure
out
to do it is to
- force a flat namespace using DYLD_FORCE_FLAT_NAMESPACE
- link applications with -multiply_defined -u foo_hack()
- add foo_hack() into scalable_malloc.c along with the hooks we need
- include the scalable_malloc.o object in our lib.
As I understand it (I didn't come up with it) this forces the rtld to
load our scalable_malloc.o rather than the one from libc, since
the first
thing it does is to go looking for foo_hack().
mach_override is evil. Really evil. Patching someone else's runtime
without
using hooks is stupid. It's even more stupid when their runtime has
hooks
that you can use already.
I've already told you in private email how to subvert the default
allocator for
malloc. Since the topic is so popular, I'll go over it in public
again. 8)
It's really quite simple.
1) include <malloc/malloc.h>
2) call malloc_default_zone() and look at the version number in the
returned
structure. If it's not one you recognise, abort(). This is
important; there is no
guarantee of compatibility if the version numbers change.
3) save the relevant vectors out of the default zone's malloc_zone_t,
overwrite
them with pointers to your interpose functions.
Presto, you're on the call chain for calls to the default allocator.
You can either
never call it again, or just mangle things and pass them through.
Be aware that the default allocator isn't the only allocator in the
system, it's just
the one that backs malloc(). Do not mess with the reserved fields,
the comments
there are not for show.
Don't try to cook up another malloc_zone_t and put the default
allocator's function
vectors in there; it depends on the default malloc_zone_t being
embedded at the
head of it's internal datastructure.
If you decide to never call the default malloc again, you will leak
about 9MB,
most of which won't be resident. That's not too bad.
For the most part, locking is not critical when you do this. You may
cause some
free() leakage if you race with the (size) and (free) swap out, but
that's about it.
= Mike
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden