Re: [Valgrind-users] RedHat 8.0 pthread "problem"

[Nicholas N. <nj...@ca...>]

On Wed, 11 Jun 2003, Beau D. Simensen wrote:

> 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=all set. However, this dumps far too
> much info to be useful for me as I have *alot* of mutex
> locking/unlocking.

First of all, it's not so unusual for a threaded program to work
differently under Valgrind;  lots of threaded programs have bugs that
happen to be "compatible" with the threading implementation they're
developed on, but break under other threading implementations.

However, the fact that it works with --trace-pthread=yes is very strange,
because --trace-pthread just causes a whole lot of pthread debugging info
to be printed.  I just looked through all the places where --trace-pthread
has an effect, every one of them just prints something to stderr (or
wherever stderr has been redirected to).

So I have no idea.  The only thing I can think of trying is this:  look
for everywhere that --trace-pthread has an effect in Valgrind's code...
all instances are in coregrind/vg_scheduler.c, and look very much like
this:

   if (VG_(clo_trace_pthread_level) >= 2) {        // or ">= 1"
      VG_(sprintf)(msg_buf, "something...");
      print_pthread_event(tid, msg_buf);
   }

Try commenting out the body of all of these if-statements, and see if you
still get differing behaviour with --trace-pthread=none/some/all.  That
would at least determine if the actual printing is somehow making it work
ok...

N