Re: [Valgrind-users] BerkeleyDB gets bogus errno in Valgrind

[Julian S. <js...@ac...>]

On Monday 12 May 2003 8:23 am, Tom Hughes wrote:
> In message <200...@ac...>
>
>         Julian Seward <js...@ac...> wrote:
> > Er, yes.  There's definitely some still wrong with errno handling
> > on both my glibc-2.3.2 systems.  The attached test program I made
> > doesn't work properly -- the perror calls print different stuff when
> > running on V.  I'll look into it more tomorrow night.  The strange
> > thing is the numbers returned by the errno uses are right, it's just
> > that when perror reads errno it gets junk.
>
> The errno handling in glibc 2.3.2 is horrible. Some of the routines
> in the library don't go through the procedure linkage table when they
> call the helper function that gets the address of the current thread's
> errno, so they always get glibc's version of that routine instead of
> the one that you have tried to replace it with.
>
> This works normally because libpthread calls __libc_pthread_init at
> startup and gives it a descriptor block which includes a function
> pointer which glibc uses to find the thread descriptor and hence the
> errno to use, but if you don't call that function, and if your thread
> descriptor don't match the real libpthread ones, then it all falls
> apart.

Thanks so much for this info; I do indeed implement __errno_location()
but I wasn't sure it's always getting used.  This passing of a 
descriptor block does sound like NPTL, tho, and we're operating 
glibc-2.3.2 in old PosixThreads mode so far.  We have confirmation
from Nick that the errno test program fails on glibc-2.2.X, so
something else must be broken.

> This is why wine now deliberately writes a jmp instruction over the
> first instruction of glibc's internal errno address getting routine
> so that it guarantee to get control at that point...

Hmm.  

J