This is the mail archive of the
libc-hacker@sourceware.cygnus.com
mailing list for the glibc project.
Re: (glibc-2.0.7) c++ constructors and pthreads
- To: davem@dm.cobaltmicro.com
- Subject: Re: (glibc-2.0.7) c++ constructors and pthreads
- From: Wolfram Gloger <wmglo@dent.med.uni-muenchen.de>
- Date: 18 Oct 1998 21:07:42 -0000
- CC: libc-hacker@cygnus.com
- References: <199810181708.KAA26616@dm.cobaltmicro.com>
> I have a crash case here for a program which has global c++
> constructors and links against linuxthreads, one of the c++
> constructors ends up calling malloc(), and this crashes because the
> pthread constructor has not run yet
That's strange, on the very first call, malloc() calls ptmalloc_init()
via the initial special hooks, which in turn calls
__pthread_initialize() if that symbol has been linked in. Can you
check why this is not working ?
> and malloc() wants to setup it's
> internal locks in the private area of the pthread_initial_thread.
You mean it wants to set up a thread-specific data key, right ? This,
too, happens after the call to __pthread_initialize(), so I don't see
why it should cause a problem.
> This is deadly on machines such as Sparc which have to do
> INIT_THREAD_SELF to initialize a global register to point to the
> thread information block.
This should happen somewhere in/via __pthread_initialize(),
shouldn't it ?
Regards,
Wolfram.
--
`Surf the sea, not double-u three...'
wmglo@dent.med.uni-muenchen.de