|
From: Alexander P. <gl...@go...> - 2012-01-26 15:12:23
|
> There's a couple of things you can try. First you can try to see > if your app is doing some kind of out of range memory access that > Memcheck can't detect. > > * increase the free block queue size as much as you can, with > the --freelist-vol= and --freelist-big-blocks= flags. This > increases Memcheck's ability to detect access-after-free > errors. > > * increase the default redzone size for client (application) heap > blocks by changing MC_MALLOC_REDZONE_SZB in memcheck/mc_include.h > to (eg) 128. This will massively increase Memcheck's memory > consumption, but it will also make it possible to detect overruns > of up to 128 bytes. > > Secondly you can try to see if there is some heap corruption for > non-application blocks. > > * Do the same but for the other arenas, which hold non-application > blocks. Do this by changing the value 4 (3rd param) in the > 7 back-to-back calls to arena_init in m_mallocfree.c. These > red zones are checked at block free time. > > I just tested this using the patch shown below. Unfortunately it > detects underruns of the test block, but not overruns for some > reason. Maybe you can figure out why. > > J Thanks for your comments! So far I've tried redzone sizes up to 256 bytes. Some combinations of application/non-application redzones made the crashes disappear, with others the test would crash at a different place (always in the userspace memory allocation). No memory errors were reported by Memcheck prior to those crashes (I've patched Valgrind to print the suppressed errors as well). I am now trying to add magic bits to the fields of Block and check them on every access. My another guess is that the corruption can be caused by some memory allocation routines we do not wrap, which mess up with Valgrind's allocations. |