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] |
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] |