public inbox for libc-hacker@sourceware.org
 help / color / mirror / Atom feed
* Re: Problem with __malloc_hooks :-(
       [not found] <u8vh7rval7.fsf@gromit.rhein-neckar.de>
@ 1999-10-28  8:43 ` H.J. Lu
  0 siblings, 0 replies; 3+ messages in thread
From: H.J. Lu @ 1999-10-28  8:43 UTC (permalink / raw)
  To: Andreas Jaeger; +Cc: GNU C Library

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Problem with __malloc_hooks :-(
  1999-10-28  8:47 ` H.J. Lu
@ 1999-10-28  8:53   ` Ulrich Drepper
  0 siblings, 0 replies; 3+ messages in thread
From: Ulrich Drepper @ 1999-10-28  8:53 UTC (permalink / raw)
  To: H.J. Lu; +Cc: GNU C Library

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Problem with __malloc_hooks :-(
       [not found] <m3so2vjxz4.fsf@localhost.localnet>
@ 1999-10-28  8:47 ` H.J. Lu
  1999-10-28  8:53   ` Ulrich Drepper
  0 siblings, 1 reply; 3+ messages in thread
From: H.J. Lu @ 1999-10-28  8:47 UTC (permalink / raw)
  To: drepper; +Cc: GNU C Library

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~1999-10-28  8:53 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <u8vh7rval7.fsf@gromit.rhein-neckar.de>
1999-10-28  8:43 ` Problem with __malloc_hooks :-( H.J. Lu
     [not found] <m3so2vjxz4.fsf@localhost.localnet>
1999-10-28  8:47 ` H.J. Lu
1999-10-28  8:53   ` Ulrich Drepper

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).