[Valgrind-users] RedHat 8.0 pthread "problem"

[Beau D. S. <sim...@ha...>]

Greetings,

I'm new to valgrind, but it was very highly recommended. With the =
exception of the following oddity, I'm quite happy so far.

First off, I'm pretty new to C++ and threads. I'm more of a Perl guy. =
Trying to figure out my problem, I've seen a number of posts where =
people say, "but it works when I don't use valgrind!" Given some of the =
problems I've had over the last four months dealing with random C++ or =
thread problems, I'm not about to assume that just because my code runs =
in its current state that there isn't anything wrong with it. =3D) =
However, I'm not entirely convinced that it isn't something tweaky in =
valgrind's pthread emulation since there are so many thread disclaimers =
all over the place...

The program I've written is currently doing the following:

 o Main thread loops, checking a list of remote request handlers to see =
if one of them needs to be queued up for a client [most of them are =
scheduled based on time, some of them based on other criteria]. If a =
request handler is ready to be executed, it pushes a request onto one of =
two client connection queues.

 o Two client connection threads wait for new requests to show up in =
their queues. When one is found, a connection is opened if one isn't =
already opened, the request is sent to the server, and the response is =
read. Connection closes after X number of seconds that the connection =
hasn't been used.


Now, this works outside of valgrind. Pretty well -- I haven't noticed =
any problems with it and other memory debugging stuff seems to think it =
is OK [for the most part]. I can actually make it "work" in valgrind, =
but only if I have --trace-pthread=3Dall set. However, this dumps far =
too much info to be useful for me as I have *alot* of mutex =
locking/unlocking. [I've since learned how to use semaphores. When I get =
a spare week or two I'll rewrite it all again... =3D)]

If it ran w/o all the pthread trace stuff, I'd be super happy! I'd =
prolly be able to move on and start using valgrind all the time [there =
are lots of other little thingies in the log that need addressing... =
memleaks, etc.] but I don't wanna run with all pthread-trace. And I'm =
not sure why it should matter. How does --trace-pthread=3Dall differ =
from --trace-pthread=3Dsome or --trace-pthread=3Dnone?

The way the application behaves when -trace-pthread=3D is set to =
anything but 'all' is that one of the threads just locks. Or something? =
The first request [authenticate] actually goes out and is read just like =
it should. However, the next two requests get lost somewhere. The caller =
[main thread] seems to think that the second/third request has gone =
'stale', which is what happens if the request isn't marked finished =
within X number of time.

The odd thing is that the second client connection thread seems to not =
have this problem [that I can see]. It executes its one request every X =
number of seconds as it should, as per the main thread says it should.

Again, it works like a charm outside of valgrind. It works with valgrind =
if --trace-pthread=3Dall . No worky if -trace-pthread=3D none or some. I =
can try and provide as much info as needed. I'd really like to be able =
to use valgrind because it looks like it can do alot of really great =
things, but I can't really use it to test too much if my code doesn't =
actually run under it. I'll provide any other information needed if more =
info is needed.

System Environment:

RedHat-8.0
 o glibc-2.2.93-5
 o glibc-devel-2.2.93-5
 o gcc-g++-3.2-7
 o valgrind-1.9.6


Thanks!


Beau D. Simensen
http://www.halogen.org/