This is the mail archive of the libc-hacker@sourceware.org mailing list for the glibc project.

Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Fix mtrace vs. mudflap coexistence


Hi,

> When an application linked with alternate malloc implementation that
> internally calls the glibc (next) malloc (such as when built with
> mudflap) is mtraced and the alternate malloc doesn't allow reentrancy,
> the application hangs.

An alternative viewpoint would be that the alternate malloc
implementation which _knows_ it is calling the glibc malloc (and which
_knows_ that itself is not reentrant-safe...) needs to reset the glibc
malloc hooks to zero before calling dlsym (RTLD_NEXT, "malloc") and
friends.

Of course this would lose the ability to mtrace that particular
alternate malloc implementation, however with your patch we
effectively lose the ability to mtrace _any_ alternate malloc
implementation.  I'm unsure which is better.

Regards,
Wolfram.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]