|
From: Tom H. <th...@cy...> - 2004-03-07 13:47:43
|
In message <1078097773.30493.134.camel@localhost.localdomain>
Jeremy Fitzhardinge <je...@go...> wrote:
> On Sun, 2004-02-29 at 14:16, Tom Hughes wrote:
> > In message <1078091257.30493.82.camel@localhost.localdomain>
> > Jeremy Fitzhardinge <je...@go...> wrote:
> >
> > > my_malloc ends up calling real malloc(), which on some libc's ends up
> > > calling init_libc_tsd_keys recursively. The mutex is already held, so
> > > it fails the second time through.
> >
> > Doesn't init_libc_tsd_keys already check for recursive calls before
> > trying to do the lock though?
>
> Not correctly. The recursion path is:
>
> init_libc_tsd_keys ->
> __pthread_key_create ->
> get_or_allocate_specifics_ptr ->
> my_malloc ->
> malloc ->
> ... ->
> init_libc_tsd_keys
>
> init_libc_tsd_keys doesn't set libc_specifics_inited until after calling
> __pthread_key_create.
>
> Perhaps it should set it as early as possible.
That wouldn't really solve the problem though. The problem is that
valrind's libpthread is trying to use malloc to allocate space for
the libc specific's, but at least one those specifics is used by
the libc malloc which just can't work...
If you look at glibc you'll see that it doesn't use the general
pthread thread specific data system to handle the libc specific
data, presumably because of this malloc issue. Instead it has a
small fixed arrary of libc specific pointers in each thread's
descriptor.
I've created a patch to move the libc specifics into the thread
state array that I created to handle errno etc so that there is
no need to use malloc, and that seems to solve the problem.
The patch is attached, and I'll commit it later on unless somebody
spots a problem with it.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|