Menu
▾
▴
valgrind-users
|
From: Vijay K. <vij...@wi...> - 2003-06-23 13:14:49
|
I've a program which makes dns client query using res_search(...). The program runs fine without valgrind, but when I run it through valgrind res_search() returns error! valgrind doesn't show any error! Any idea why this could happen? Thanks. Vijay |
|
From: Dirk M. <dm...@gm...> - 2003-06-23 13:51:02
|
On Mon, 23 Jun 2003, Vijay Kamath wrote: > I've a program which makes dns client query using res_search(...). > The program runs fine without valgrind, but when I run it through > valgrind res_search() returns error! valgrind doesn't show any error! > Any idea why this could happen? can you do a small testcase showing the problem? -- Dirk |
|
From: Vijay K. <vij...@wi...> - 2003-06-23 14:32:35
|
Dirk Mueller wrote: >On Mon, 23 Jun 2003, Vijay Kamath wrote: > > > >>I've a program which makes dns client query using res_search(...). >>The program runs fine without valgrind, but when I run it through >>valgrind res_search() returns error! valgrind doesn't show any error! >>Any idea why this could happen? >> >> > >can you do a small testcase showing the problem? > > I tried reproducing the problem by writing a small program that tests this call, it passed and valgrind did not show any problem. It happens only in my production code. And unfortunately it is too big to be shown here. So if there is a problem, it should be with my code, but I have no idea what it could be. And why doesn't valgrind show any error?! Any help will be greatly appreciated. > > > |
|
From: Dirk M. <dm...@gm...> - 2003-06-23 15:07:07
|
On Mon, 23 Jun 2003, Vijay Kamath wrote: > idea what it could be. And why doesn't valgrind show any error?! are you suere the very same parameters being passed to the function? Maybe valgrind triggers another bug else where and the parameters you pass to the function while running under valgrind are not the same. do you use threads? can you try with CVS HEAD version ? can you try with --optimise=no --chain-bb=no ? -- Dirk |
|
From: Vijay K. <vij...@wi...> - 2003-06-24 03:47:27
Attachments:
res.cpp
|
I was able to reproduce the problem. It occurs if I'm using threads. I've attached a sample code that causes this problem. The code fails when run with valgrind, but passes without it. Please let me know where is the problem - resolv, pthread, valgrind, my code ?? Any help would be great. Thanks. Vijay Dirk Mueller wrote: >On Mon, 23 Jun 2003, Vijay Kamath wrote: > > > >>idea what it could be. And why doesn't valgrind show any error?! >> >> > >are you suere the very same parameters being passed to the function? >Maybe valgrind triggers another bug else where and the parameters you pass >to the function while running under valgrind are not the same. > >do you use threads? > >can you try with CVS HEAD version ? > >can you try with --optimise=no --chain-bb=no ? > > > > > |
|
From: Jeremy F. <je...@go...> - 2003-06-24 07:31:06
|
On Mon, 2003-06-23 at 20:47, Vijay Kamath wrote: > I was able to reproduce the problem. It occurs if I'm using threads. > I've attached a sample code that causes this problem. The code fails > when run with valgrind, but passes without it. > Please let me know where is the problem - resolv, pthread, valgrind, my > code ?? > > Any help would be great. Hm, I can reproduce this here on both my RH8 and RH9 machines. I'm guessing it has something to do with thread-specific data, but it isn't related to the new TLS stuff. I can't see anything obvious with --trace-pthread=all. J |
|
From: Vijay K. <vij...@wi...> - 2003-06-25 03:14:33
|
Any updates on this? Vijay On 24 Jun 2003 00:31:04 -0700, Jeremy Fitzhardinge <je...@go...> wrote: > On Mon, 2003-06-23 at 20:47, Vijay Kamath wrote: >> I was able to reproduce the problem. It occurs if I'm using threads. >> I've attached a sample code that causes this problem. The code fails >> when run with valgrind, but passes without it. >> Please let me know where is the problem - resolv, pthread, valgrind, my >> code ?? >> >> Any help would be great. > > Hm, I can reproduce this here on both my RH8 and RH9 machines. I'm > guessing it has something to do with thread-specific data, but it isn't > related to the new TLS stuff. I can't see anything obvious with > --trace-pthread=all. > > J > > |
|
From: Dirk M. <dm...@gm...> - 2003-06-25 09:30:31
|
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. -- Dirk |
|
From: Julian S. <js...@ac...> - 2003-07-09 00:42:43
|
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 |
|
From: Dan K. <da...@ke...> - 2003-07-09 01:01:06
|
Julian Seward wrote: > 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). Did you get no response to your earlier message, http://sources.redhat.com/ml/libc-alpha/2003-05/msg00145.html ? - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045 |
|
From: Julian S. <js...@ac...> - 2003-07-09 20:06:53
|
On Wednesday 09 July 2003 02:18, Dan Kegel wrote: > Julian Seward wrote: > > 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). > > Did you get no response to your earlier message, > http://sources.redhat.com/ml/libc-alpha/2003-05/msg00145.html > ? No, in a word. J |
|
From: Julian S. <js...@ac...> - 2003-07-10 00:38:14
|
Ok, I've just committed to cvs an alternative function-call intercept scheme which works around this, and causes the res_search test case associated with this thread, to work properly on my SuSE 8.2 (glibc-2.3.2) box. So I think it's sorted. J On Wednesday 09 July 2003 21:06, Julian Seward wrote: > On Wednesday 09 July 2003 02:18, Dan Kegel wrote: > > Julian Seward wrote: > > > 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). > > > > Did you get no response to your earlier message, > > http://sources.redhat.com/ml/libc-alpha/2003-05/msg00145.html > > ? > > No, in a word. > > J > > > > ------------------------------------------------------- > This SF.Net email sponsored by: Parasoft > Error proof Web apps, automate testing & more. > Download & eval WebKing and get a free book. > www.parasoft.com/bulletproofapps > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X