Neither of these tools understand custom malloc functions. But it's easy to tech them.
Way1: hack the dlmalloc code to include helgrind's client requests (see helgrind.h in valgrind distro) Way2: hack helgrind to intercept the custom malloc functions. ThreadSanitizer (code.google.com/p/data-race-test/wiki/ThreadSanitizer) uses this way, but it is not a part of the valgrind distro. Let us know if you need more details (sorry, have to run too :) --kcc On Wed, Apr 29, 2009 at 9:56 PM, <[email protected]> wrote: > > 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 > > ------------------------------------------------------------------------------ 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
