Konstantin,
The first method you suggest sounds the best for maintaining the changes
necessary in the one product that necessitates them:
"Way1: hack the dlmalloc code to include helgrind's client requests
(see helgrind.h in valgrind distro)"
I apologize, however, and must admit my ignorance as to what this would
entail. I looked at the helgrind.h header and saw:
#include "valgrind.h"
typedef
enum {
VG_USERREQ__HG_CLEAN_MEMORY = VG_USERREQ_TOOL_BASE('H','G'),
/* The rest are for Helgrind's internal use. Not for end-user
use. Do not use them unless you are a Valgrind developer. */
/* Notify the tool what this thread's pthread_t is. */
_VG_USERREQ__HG_SET_MY_PTHREAD_T = VG_USERREQ_TOOL_BASE('H','G')
+ 256,
....
/* Clean memory state. This makes Helgrind forget everything it knew
about the specified memory range, and resets it to New. This is
particularly useful for memory allocators that wish to recycle
memory. */
#define VALGRIND_HG_CLEAN_MEMORY(_qzz_start, _qzz_len) \
If you mean I should add this macro to any memory location returned from
the various methods in dlmalloc, would this be the equivalent of simply
removing dlmalloc.c from the makefile and using the default allocator?
If this is the case, I have yet to see any helgrind reports when this is
done (I tried this early on.) However, the line I first listed actually
DID have a Race condition (since fixed) in the SendHandler code that was
not noticed before. It was not possible that this was the problem as
instrumentiation proves this call was done once at startup and never again
(it was a reconnect code gone awry) in testing. Yet we got those errors.
I started wondering if it was something related to something presumably
allocated in (in /usr/lib64/libstdc++.so.6.0.3) and freed in
(dlmalloc-2.8.3.c:2416) due to:
==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)
...
==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)
...
I am, as I said, ignorant in this area - but I'd assume that libstdc is
using dlmalloc if it is compiled in since the library exporting
SendHandler is a librnrfw.a file (if that even makes a difference)
But I was reaching for any clues...
In the past (3.1.x?) when I used Helgrind, it found me very clear "x is
writing to y without using previously used z mutex" style errors which
helped find some sneaky errors in code I was debugging. This time, I don't
even know what is being referred to in order to infer some ideas as to the
cause.
ie: What is "size 1"? What is "0x82bee0" (which is always the address
being reported every time) - is it the address of some dlmalloc method,
variable?
Thanks again - I'm ... unfortunately... the "valgrind expert" here, since
I wrote a suppressions system for our apps and have read the manual...
obviously that an "expert" does not make by any stretch :) so here I am
confused.
In case this helps in your answe:
... snipped from dlmalloc-2.8.3.c source file...
...
/* ------------------- Declarations of public routines -------------------
*/
#ifndef USE_DL_PREFIX
#define dlcalloc calloc
#define dlfree free
#define dlmalloc malloc
#define dlmemalign memalign
#define dlrealloc realloc
#define dlvalloc valloc
#define dlpvalloc pvalloc
#define dlmallinfo mallinfo
#define dlmallopt mallopt
#define dlmalloc_trim malloc_trim
#define dlmalloc_stats malloc_stats
#define dlmalloc_usable_size malloc_usable_size
#define dlmalloc_footprint malloc_footprint
#define dlmalloc_max_footprint malloc_max_footprint
#define dlindependent_calloc independent_calloc
#define dlindependent_comalloc independent_comalloc
#endif /* USE_DL_PREFIX */
/*
malloc(size_t n)
Returns a pointer to a newly allocated chunk of at least n bytes, or
null if no space is available, in which case errno is set to ENOMEM
on ANSI C systems.
If n is zero, malloc returns a minimum-sized chunk. (The minimum
size is 16 bytes on most 32bit systems, and 32 bytes on 64bit
systems.) Note that size_t is an unsigned type, so calls with
arguments that would be negative if signed are interpreted as
requests for huge amounts of space, which will often fail. The
maximum supported value of n differs across systems, but is in all
cases less than the maximum representable value of a size_t.
*/
void* dlmalloc(size_t);
/*
free(void* p)
Releases the chunk of memory pointed to by p, that had been previously
allocated using malloc or a related routine such as realloc.
It has no effect if p is null. If p was not malloced or already
freed, free(p) will by default cause the current program to abort.
*/
void dlfree(void*);
... more stuff ...
Konstantin Serebryany <[email protected]>
04/29/2009 02:33 PM
To
Daniel Delgado/comst...@spc
cc
[email protected]
Subject
Re: [Valgrind-users] dlmalloc and helgrind (drd?) ?
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
