Hello all,
This is my first post. I am using Valgrind 3.4.1. The application I was
testing for what seems to be memory corruption is compiled along with
dlmalloc-2.8.3.c
Has anyone had experience with this? Will I be seeing "false positives"?
If I recall, I had used this in a past (3.1?) Valgrind and had to remove
dlmalloc due to too many reports from helgrind - my memory is poor but I
seem to recall something of the sort. Right now, it is only reporting a
very small amount of entries and they do seem to be around 'fishy' code
for the most part.
However, one such report has me baffled, it usually appears in most all
reports:
==28103== Thread #3 was created
==28103== at 0x3329FC3AE1: clone (in /lib64/tls/libc-2.3.3.so)
==28103== by 0x332BB0645D: pthread_create@@GLIBC_2.2.5 (in
/lib64/tls/libpthread-2.3.3.so)
==28103== by 0x4907974: pthread_cre...@* (hg_intercepts.c:214)
==28103== by 0x608694: tp::Thread::start() (Thread.C:56)
==28103== by 0x5C831E: RnrFw::RnrFactory::startRnr()
(RnrFactory.cpp:242)
==28103== by 0x4E53F2: RnrProxy::startup() (RnrProxy.C:121)
==28103== by 0x4941FD: main (....C:894)
==28103==
==28103== Thread #1 is the program's root thread
==28103==
==28103== Possible data race during read of size 1 at 0x82bee0 by thread
#3
==28103== at 0x4A9111: free (dlmalloc-2.8.3.c:2416)
==28103== by 0x332BDAFF28: __cxa_free_exception (in
/usr/lib64/libstdc++.so.6.0.3)
==28103== by 0x5D3051: RnrFw::SendHandler::send(char const*, unsigned
long) (SendHandler.cpp:120)
..stack trace snipped
==28103== by 0x49078C3: mythread_wrapper (hg_intercepts.c:194)
==28103== by 0x332BB05F80: start_thread (in
/lib64/tls/libpthread-2.3.3.so)
==28103== by 0x3329FC3AF2: clone (in /lib64/tls/libc-2.3.3.so)
==28103== This conflicts with a previous write of size 1 by thread #1
==28103== at 0x4A9B22: malloc (dlmalloc-2.8.3.c:3407)
==28103== by 0x4D303D: SymbolDataStore::tokenAlloc(symbolRec*,
MetaToken const&, int) (symboldb.C:589)
==28103== by 0x4D33B3: SymbolDataStore::updateIToken(symbolRec*,
MetaToken const&, long) (symboldb.C:635)
... more stack trace
I suspected either something I am not seeing in the way the exception is
created or more likely (I think? ;) ) something occuring as a result of
the freeing of the exception memory after the stack was unwound - perhaps
due to dlmalloc either bug or false positive.
Note, dlmalloc is compiled into the app with -USE_LOCKS set.
Thanks!
Dan
Now, while writing this, I ran under DRD (I didn't know about this tool
until now) - I have not yet examined this as I have a meetign in 7
minutes.
==11369== Thread 3:
==11369== Conflicting load by thread 3/3 at 0x0082bf00 size 1
==11369== at 0x4A9111: free (dlmalloc-2.8.3.c:2416)
==11369== by 0x332BDAFF28: __cxa_free_exception (in
/usr/lib64/libstdc++.so.6.0.3)
==11369== by 0x5D3081: RnrFw::SendHandler::send(char const*, unsigned
long) (SendHandler.cpp:121)
..snipped stack trace...
==11369== by 0x49085BE: vg_thread_wrapper
(drd_pthread_intercepts.c:193)
==11369== by 0x332BB05F80: start_thread (in
/lib64/tls/libpthread-2.3.3.so)
==11369== by 0x3329FC3AF2: clone (in /lib64/tls/libc-2.3.3.so)
==11369== Allocation context: BSS section of /home/ddelgado/...
==11369== Other segment start (thread 1/1)
==11369== at 0x4909096: pthread_mutex_lock
(drd_pthread_intercepts.c:417)
==11369== by 0x4A9AE0: malloc (dlmalloc-2.8.3.c:3358)
==11369== by 0x48EE4B: zcalloc (in /home/ddelgado/...)
...snipped stack trace....
==11369== by 0x4944A2: main (...:954)
==11369== Other segment end (thread 1/1)
==11369== at 0x49093F4: pthread_mutex_unlock
(drd_pthread_intercepts.c:463)
==11369== by 0x4A9B31: malloc (dlmalloc-2.8.3.c:3410)
==11369== by 0x48EE4B: zcalloc (in /home/ddelgado/....)
...snipped stack trace....
==11369== by 0x4944A2: main (...:954)
Dan Delgado | Senior Software Engineer
* Interactive Data Real-Time Services | 100 Hillside Ave. | White Plains,
NY 10603 | USA
( 914-313-4296 8 [email protected]
------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance & Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
_______________________________________________
Valgrind-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
