Re: Problem with __malloc_hooks :-(

Re: Problem with __malloc_hooks :-(

[H.J. Lu]

> 
> 
> The following program shows a problem I noticed with a current glibc
> 2.1.3 CVS versions and XEmacs [1]:
> 
> #define _GNU_SOURCE 
> #include <stdlib.h>
> #include <malloc.h>
> 
> int
> main (int argc, char argv[])
> {
>   char *p;
>   
>   if (argc == 1)
>     {
>       __malloc_hook = NULL;
>       __realloc_hook = NULL;
>       __free_hook = NULL;
>     }
> 
>   p = malloc (1000);
>   printf ("%p\n", p);
>   return 0;
> }
> 
> Have a look at the output:
> 
> gromit:/tmp:[0]$ ./malloc 
> (nil)
> gromit:/tmp:[0]$ ./malloc 1
> 0x8049670
> 
> If __malloc_hook is NULL, malloc returns NULL.  The problem is that
> malloc internally uses __malloc_hook and the current CVS version
> doesn't call malloc before main any more :-(.
> 
> Wolfram, can you give me some feedback, please?
> 

Ulrich, I have verified that my preinit patch works fine. It seems that
my patch has more than one benefit. Maybe it should be considered
instead of your patch to exit/atexit.

-- 
H.J. Lu (hjl@gnu.org)

Re: Problem with __malloc_hooks :-(

[H.J. Lu]

> 
> hjl@lucon.org (H.J. Lu) writes:
> 
> > Have you tried my preinit patch? It is for the static libpthread bug
> > which Ulrich fixed with a different approach. But it seems that my
> > patch has other potential benefits :-).
> 
> Of course this patch would change the behaviour but you cannot
> honestly believe I would use it.  I'm not yet sure at all whether
> there is a real problem.  If there is one it has to be fixed at the
> source and not worked around by such a hack.
> 

You can call it a hack if you want. The preinit issue is a real
problem. It also happens to other people. I believe that is why
DT_PREINIT_XXXX was invented. I belive glibc 2.1.x should support
preinit in one form or the other.


-- 
H.J. Lu (hjl@gnu.org)

Re: Problem with __malloc_hooks :-(

[Ulrich Drepper]

hjl@lucon.org (H.J. Lu) writes:

> You can call it a hack if you want. The preinit issue is a real
> problem. It also happens to other people. I believe that is why
> DT_PREINIT_XXXX was invented. I belive glibc 2.1.x should support
> preinit in one form or the other.

Wait a minute.  This are two completely different things.  Supporting
preinit is fine, but using it to fix a completely unrelated issue is
not acceptable.  Beside, glibc does not have to use the feature to
support it.  Especially since adding a preinit table to libc.so will
not help at all since it is never used (except if libc.so is executed
directly).

-- 
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------