Re: [Valgrind-users] valgrind and dns queries

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

On Wednesday 25 June 2003 10:30, Dirk Mueller wrote:
> On Mit, 25 Jun 2003, Vijay Kamath wrote:
> > Any updates on this?
>
> I can reproduce the problem. I don't know what the exact problem is though
> or how to fix it.

The problem doesn't occur on glibc-2.2.X systems, according to my
regression tests.  So far I have only confirmation of it on glibc-2.3.2
(SuSE 8.2).  And the failure only occurs if the call to res_search happens
in a thread which is not the main thread.

In vg_libpthread.c, see the function __res_state() (line 1640 in cvs).
If it is modified to always return & _res regardless of tid, the failure
no longer occurs.  This is not however a good fix.

I have seen this kind of problem before with glibc-2.3.2, when
handling errno.  (The Wine people also got hit by errno problems).
The resolver depends on some thread-specific state.  Usually it
obtains a pointer to the thread's state block, by calling __res_state().
Problem occurs (probably) because somewhere in libc or libresolv,
this mechanism is bypassed, and _res, which holds the resolver state
for the root thread, is incorrectly used regardless of the thread id.

This might be due to over-enthusiastic PLT bypassing.  Certainly it
makes it impossible for valgrind to make the resolver work correctly
in threaded programs on glibc-2.3.2 based systems.

As a point of reference, we have confirmed that the same problem
happens with handling of errno on glibc-2.3.2: references to errno
should turn into *__errno_location(), and it would all work fine if it
always did consistently, but in glibc-2.3.2 it doesn't.

I guess the only advice I can offer is to avoid glibc-2.3.2 based systems
at the moment, and to ask the glibc people to fix this bug (never do 
PLT bypassing for calls to __errno_location, __h_errno_location or
 __res_state).

If anyone has any further clarifications/insights into this I would be
grateful to hear them.

J