Re: [Valgrind-users] Valgrind'ing multiple threads

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Sigh ... 

Sure, our threading library normally handles this fine.  However
there are big problems on dealing with threading in systems
with glibc 2.3.2 and later, and this is one of them.

Are you able to build / run your app on a distro with 
glibc of 2.3.1 or earlier?  That might help.  (Test with
your tiny test program first ...)

J

On Thursday 24 April 2003 8:54 pm, Alex Ivershen wrote:
> <!doctype html public "-//w3c//dtd html 4.0 transitional//en">
> <html>
> Hi all,
> <p>I am observing a strange behaviour while trying to valgrind my
> mutlithreaded programs.&nbsp; I wrote a trivial test program with two
> threads and the behaviour replicates what I am seeing in my apps. Here is
> the scenario - application spawns two threads. First one opens a socket and
> is doing blocking recv().&nbsp; Then the second one is spawned to do
> something else.&nbsp; Works just fine without valgrind.
> <p>What happens in valgrind, when the first thread, socket listener, is
> spawned, it executes in the context of main thread. This causes the main
> thread to block on recv(), and as consequence the program never goes any
> further, not spawning the second thread, not doing anything.&nbsp; I do
> know you are using your own substitute for pthreads library, but I cannot
> imagine that you mutilating it so much as to collapse all application
> threads into one.
> <p>I am using RH8 Linux with glibc-2.3.2-4.80, kernel 2.4.18-26.8.0smp,
> compiling with gcc 2.95.3 (can't go higher because of source code
> dependencies issues). I am including source code for the little test
> program and backtrace after it's stuck in recv() - you can see that
> everything is in one thread, and gdb does not show any more threads
> whatsoever.
> <p>So, if you could solve the mystery for me, it will be much appreciated!
> I cannot wait to get my hands on all the features that the manual talks
> about - and from general Linux community buzz you guys are much better
> then Rational Purify.
> <p>Regards,
> <br>Alex
> <p>(gdb) bt
> <br>#0&nbsp; 0x400bb262 in vgPlain_do_syscall () from
> /home/agi/linux/lib/valgrind/valgrind.so <br>#1&nbsp; 0x400a8c1e in
> vgIntercept_recv (s=4, buf=0x40e53b10, len=1000, flags=0) at
> vg_intercept.c:152
> <br>#2&nbsp; 0x400a8c34 in recv (s=4, buf=0x40e53b10, len=1000, flags=0)
> at vg_intercept.c:157
> <br>#3&nbsp; 0x08048790 in ListenerStart(void*) (pParm=0x0) at main.cpp:59
> <br>#4&nbsp; 0x4013a58d in thread_wrapper (info=0xfffffe00) at
> vg_libpthread.c:671 <br>#5&nbsp; 0x4009ab80 in
> do__apply_in_new_thread_bogusRA () at vg_scheduler.c:2155 <br>#6&nbsp;
> 0x08048695 in main () at main.cpp:25
> <br>#7&nbsp; 0x401794ad in __libc_start_main () from /lib/libc.so.6
> <pre>--&nbsp;
> Alex G.
> Ivershen&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&
>nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
>;&nbsp;&nbsp;&nbsp; Inet Technologies, Inc. Network Products
> Dept.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs
>p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1500 N. Greenville
> Ave. Inet Technologies
> Inc.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
>;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Richardson, TX 75081
> Phone:
> +1-469-330-4295&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; USA
>
> "Black Holes are where God divided by zero"</pre>
> &nbsp;</html>