Menu
▾
▴
Re: [Valgrind-users] Valgrind'ing multiple threads
|
From: Todd R. <ric...@pr...> - 2003-04-24 20:38:16
|
Your code should work fine on a glibc 2.3.1 system such as plain vanilla,
freshly installed Redhat 8. If you require Redhat 9 or patches to 8(which
may upgrade to 2.3.2) , you will have to wait for a valgrind update
Todd
----- Original Message -----
From: "Julian Seward" <js...@ac...>
To: "Alex Ivershen" <ale...@in...>; "Nicholas Nethercote"
<nj...@ca...>
Cc: <val...@li...>
Sent: Thursday, April 24, 2003 1:22 PM
Subject: Re: [Valgrind-users] Valgrind'ing multiple threads
>
> 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. 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(). Then the second one is spawned to do
> > something else. 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. 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 0x400bb262 in vgPlain_do_syscall () from
> > /home/agi/linux/lib/valgrind/valgrind.so <br>#1 0x400a8c1e in
> > vgIntercept_recv (s=4, buf=0x40e53b10, len=1000, flags=0) at
> > vg_intercept.c:152
> > <br>#2 0x400a8c34 in recv (s=4, buf=0x40e53b10, len=1000, flags=0)
> > at vg_intercept.c:157
> > <br>#3 0x08048790 in ListenerStart(void*) (pParm=0x0) at
main.cpp:59
> > <br>#4 0x4013a58d in thread_wrapper (info=0xfffffe00) at
> > vg_libpthread.c:671 <br>#5 0x4009ab80 in
> > do__apply_in_new_thread_bogusRA () at vg_scheduler.c:2155 <br>#6
> > 0x08048695 in main () at main.cpp:25
> > <br>#7 0x401794ad in __libc_start_main () from /lib/libc.so.6
> > <pre>--
> > Alex G.
> >
Ivershen &
>
>nbsp; &nbs
p
> >; Inet Technologies, Inc. Network Products
> >
Dept. &nbs
> >p; 1500 N.
Greenville
> > Ave. Inet Technologies
> >
Inc.  
> >; Richardson, TX
75081
> > Phone:
> >
+1-469-330-4295
> > USA
> >
> > "Black Holes are where God divided by zero"</pre>
> > </html>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
|
