Hi Bart,
<[email protected]> 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
------------------------------------------------------------------------------ Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev
_______________________________________________ Valgrind-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/valgrind-users
