Re: [PATCH] Fix mtrace vs. mudflap coexistence

[Wolfram Gloger <wmglo@dent.med.uni-muenchen.de>]

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.