|
From: Aleksander <val...@al...> - 2009-12-10 00:08:16
|
Hi all, Can someone explain the error shown below? It's in a glib-based application, and it seems that DRD doesn't like the call to send() in libpthread while creating a new thread at the same time... Why is this wrong? I really tried to understand the output, but got completely stuck, as this is actually the first time I am trying DRD, which by the way, called as: export G_SLICE=always-malloc ./vg-in-place --tool=drd --check-stack-var=yes --show-stack-usage=yes Using self-compiled valgrind 3.5 in RHEL5.2 Thanks in advance, -Aleksander ----------------------------------- ==19314== Conflicting load by thread 6 at 0x39ba019310 size 4 ==19314== at 0x39B9E0D192: send (in /lib64/libpthread-2.5.so) ==19314== by 0x4C342D0: __jardin_connection_module_send_impl (jardin_connection_module.c:863) ==19314== by 0x4C3537C: __jardin_client_send_receive_impl (jardin_client_obj.c:869) ==19314== by 0x3915406CEF: __wzt_scmp_client_send_recv_timeout_impl (wzt_scmp_client.c:361) ==19314== by 0x400EA8: wzt_scmp_client_send_recv_timeout (in /home/aleksander/Development/scmp_client2) ==19314== by 0x400B42: __send_message (in /home/aleksander/Development/scmp_client2) ==19314== by 0x40123F: __thread_func (in /home/aleksander/Development/scmp_client2) ==19314== by 0x39BBA48F23: ??? (in /lib64/libglib-2.0.so.0.1200.3) ==19314== by 0x4A0C42F: vgDrd_thread_wrapper (drd_pthread_intercepts.c:272) ==19314== by 0x39B9E062F6: start_thread (in /lib64/libpthread-2.5.so) ==19314== by 0x39B92D1B6C: clone (in /lib64/libc-2.5.so) ==19314== Allocation context: BSS section of /lib64/libpthread-2.5.so ==19314== Other segment start (thread 1) ==19314== at 0x4A0D016: pthread_mutex_lock (drd_pthread_intercepts.c:580) ==19314== by 0x39BBA48DA0: g_thread_create_full (in /lib64/libglib-2.0.so.0.1200.3) ==19314== by 0x401330: main (in /home/aleksander/Development/scmp_client2) ==19314== Other segment end (thread 1) ==19314== at 0x39B92D1B31: clone (in /lib64/libc-2.5.so) ==19314== by 0x39B9E068ED: pthread_create@@GLIBC_2.2.5 (in /lib64/ libpthread-2.5.so) ==19314== by 0x4A12F36: pthread_create@* (drd_pthread_intercepts.c:409) ==19314== by 0x39C120209B: ??? (in /lib64/libgthread-2.0.so.0.1200.3) ==19314== by 0x39BBA48DCE: g_thread_create_full (in /lib64/libglib-2.0.so.0.1200.3) ==19314== by 0x401330: main (in /home/aleksander/Development/scmp_client2) ==19314== Other segment start (thread 1) ==19314== at 0x4A0D016: pthread_mutex_lock (drd_pthread_intercepts.c:580) ==19314== by 0x39BBA48DA0: g_thread_create_full (in /lib64/libglib-2.0.so.0.1200.3) ==19314== by 0x401330: main (in /home/aleksander/Development/scmp_client2) ==19314== Other segment end (thread 1) ==19314== at 0x39B92D1B31: clone (in /lib64/libc-2.5.so) ==19314== by 0x39B9E068ED: pthread_create@@GLIBC_2.2.5 (in /lib64/ libpthread-2.5.so) ==19314== by 0x4A12F36: pthread_create@* (drd_pthread_intercepts.c:409) ==19314== by 0x39C120209B: ??? (in /lib64/libgthread-2.0.so.0.1200.3) ==19314== by 0x39BBA48DCE: g_thread_create_full (in /lib64/libglib-2.0.so.0.1200.3) ==19314== by 0x401330: main (in /home/aleksander/Development/scmp_client2) |
|
From: Bart V. A. <bar...@gm...> - 2009-12-10 07:26:07
|
On Thu, Dec 10, 2009 at 1:08 AM, Aleksander <val...@al...> wrote: > Can someone explain the error shown below? > > It's in a glib-based application, and it seems that DRD doesn't like the > call to send() in libpthread while creating a new thread at the same time... > Why is this wrong? > > [ ... ] > > ==19314== Conflicting load by thread 6 at 0x39ba019310 size 4 > ==19314== at 0x39B9E0D192: send (in /lib64/libpthread-2.5.so) > ==19314== by 0x4C342D0: __jardin_connection_module_send_impl > (jardin_connection_module.c:863) > [ ... ] ==19314== Allocation context: BSS section of /lib64/libpthread-2.5.so > [ ... ] DRD uses the Valgrind core to print a call stack when a conflicting memory access has been detected. I'm not sure the library information in the above call stack is correct: as far as I know send() is a function that has been implemented in libc and not in libpthread. If it's not clear why DRD reports a conflicting memory access, the following will help: - Start from the address on which a conflicting memory access has been reported, and find out with which data structure in the source code program this address corresponds. If you don't have a clue, inspect your program at the time the conflicting memory access was reported with --db-attach=yes. - Find out where the data structure has been allocated. If the memory has been allocated dynamically, insert a DRD_TRACE_VAR(...) statement just after the allocation. If it's a global or static variable, insert the DRD_TRACE_VAR(...) macro in a function that is called before the data structure is used. See also the Valgrind manual for more information about the DRD_TRACE_VAR() macro. Bart. |
|
From: Aleksander <val...@al...> - 2009-12-10 13:12:11
|
Hi Bart,
<val...@al...> wrote:
> > Can someone explain the error shown below?
> >
> > It's in a glib-based application, and it seems that DRD doesn't like the
> > call to send() in libpthread while creating a new thread at the same
> time...
> > Why is this wrong?
> >
> > [ ... ]
> >
> > ==19314== Conflicting load by thread 6 at 0x39ba019310 size 4
> > ==19314== at 0x39B9E0D192: send (in /lib64/libpthread-2.5.so)
> > ==19314== by 0x4C342D0: __jardin_connection_module_send_impl
> > (jardin_connection_module.c:863)
> > [ ... ]
> ==19314== Allocation context: BSS section of /lib64/libpthread-2.5.so
> > [ ... ]
>
> DRD uses the Valgrind core to print a call stack when a conflicting
> memory access has been detected. I'm not sure the library information
> in the above call stack is correct: as far as I know send() is a
> function that has been implemented in libc and not in libpthread.
>
>
Just listed symbols in libpthread.a, and found:
0000000000000000 T __libc_send
0000000000000000 W __send
0000000000000000 W send
Where the "W", seems to mean that is a weak symbol that if found in another
library, it will use the `send' from that other library.
In the library doing the actual send(), the nm output shows:
U send@@GLIBC_2.2.5
So in theory, this means that, when linking to libpthread, the send() used
will be the one in libpthread, which in fact then will be the one from
libc... something like that?
If it's not clear why DRD reports a conflicting memory access, the
> following will help:
> - Start from the address on which a conflicting memory access has been
> reported, and find out with which data structure in the source code
> program this address corresponds. If you don't have a clue, inspect
> your program at the time the conflicting memory access was reported
> with --db-attach=yes.
> - Find out where the data structure has been allocated. If the memory
> has been allocated dynamically, insert a DRD_TRACE_VAR(...) statement
> just after the allocation. If it's a global or static variable, insert
> the DRD_TRACE_VAR(...) macro in a function that is called before the
> data structure is used.
>
Actually, the error is only shown when using "--check-stack-var=yes" drd
option, so I guess it's not dynamically allocated.
> See also the Valgrind manual for more information about the
> DRD_TRACE_VAR() macro.
>
>
I looked at the online manual, and for DRD_TRACE_VAR() it says I should
specify an "address range". I don't understand that quite well, though. Is
it just putting DRD_TRACE_VAR(variable) in the code? By "address range" is
meant the address range occupied by the whole variable?
Cheers and thanks,
-Aleksander
|
|
From: Bart V. A. <bar...@gm...> - 2009-12-10 17:37:53
|
On Thu, Dec 10, 2009 at 2:12 PM, Aleksander <val...@al...> wrote: >> See also the Valgrind manual for more information about the >> DRD_TRACE_VAR() macro. > > I looked at the online manual, and for DRD_TRACE_VAR() it says I should > specify an "address range". I don't understand that quite well, though. Is it just > putting DRD_TRACE_VAR(variable) in the code? By "address range" is meant > the address range occupied by the whole variable? Indeed. I will update the DRD manual to make it more clear -- thanks for reporting this. You can find an example in the regression test program drd/tests/omp_prime.c: ... int total = 0; ... DRD_TRACE_VAR(total); ... The above trace statement is equivalent to ANNOTATE_TRACE_MEMORY(&total). Bart. |