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

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

>
> > 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.
>

OK. I read up on the FAQs, and it didn't sound like that. I guess I know
better now.


>
> 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).
>

Strange, yes. If I hadn't found this little quirk, I probably would have
wandered on and tried to find another debugging application. However, seeing
it work when flags were set a particular way gave me hope that valgrind
might work out for me....


>
> 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...
>

I commented out all of the statements that dealt with
clo_trace_pthread_level. And it was broken. [read: --trace-pthread=all
didn't "work" anymore] So I guess that it is somehow related to printing vs.
not printing. Tiny timing issues introduced by printing maybe?

There was some other stuff I left out, and I'm feeling a bit foolish now.
I'm working in an automake/autoconf project. In doing these changes and
preparing to run the stuff a few way sto see if it made a difference, I
realized I was doing some stuff I hadn't mentioned in my first email. In the
end I see the same results, but there is more stuff between point A and
point F than I let on to begin with.

The "binaries" I was running off of were not actually binaries. They were
the automake magic scripts. :-/ As the little working applications are
actually just shell scripts, running valgrind on my build would only show me
info for the shell script. So I've been running --trace-children=yes so that
I could get info [I assume] on my actual code running as well as the shell
script/other applications.

Trying to make sure I didn't just do something stupid [i.e., maybe it all
worked, just not through the magic scripts], I ran the actual pre-install
binary through valgrind as well. It seems to behave as src/testsd, but I
don't need to --trace-chilren=yes ... which is how I described the problem
to begin with (just --trace-pthread=all, not --trace-children=yes
and --trace-pthread=all).

  valgrind src/testsd
     [<shell wrapper> works!!! but I guess it only checks the shell script?]

  valgrind --trace-children=yes src/testsd
     [<shell wrapper> shows me more debug info, including stuff from my
code, but threads are broken]

  valgrind --trace-pthread=all --trace-children=yes src/testsd
     [<shell wrapper> works, but spews a whole lot of mutex locking stuff]

  valgrind src/.libs/testsd
     [<binary> shows me debug info for my code, but threads are broken]

  valgrind --trace-pthread=all src/.libs/testsd
     [<binary> works, but spews a whole lot of mutex locking stuff]


It really doesn't change the behaviour any, but it is a little different
from what I described before. I just wanted to clarify. FWIW, I also did the
following:


  # rebuild from 'scratc'
  ./bootstrap && ./configure --prefix=/home/altern8/dummy && make
install-strip

  valgrind /home/altern8/dummy/bin/testsd
     [<binary> shows me debug info for my code, but is broken]

  valgrind --trace-pthread=all /home/altern8/dummy/bin/testsd
     [<binary> works, but spews a whole lot of mutex locking stuff]


This way I am pretty sure that it is actually doing what it says it should
be doing. [read: deffinitely no automake/autoconf magic anywhere.] And it
still behaves the same way as I described before.

Hopefully this provides some hints?

I'm really happy that this list has been so helpful so far. Quick responses
and such. Very cool and greatly appreciated!

Thanks again,


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