Hi,
We have a custom allocator which I have instrumented with VALGRIND macro's so
we can run our software under valgrind and detect memory abuse and leaks.
Works great, and has done so for many years now.
That allocator used to use sbrk() to get the raw memory in large chunks, and
then uses VALGRIND_MALLOCLIKE_BLOCK when it doled out smaller chunks to the
applications.
But sbrk() does not work well when a single application uses multiple
allocators, and our software now links with 3rd party code which has its own
ideas about allocation.
That caused problems and instability.
So, our custom allocator now uses the system 'malloc()' instead of sbrk() to
allocate large chunks, which solves the interference problems between
allocators.
That stabilized the software.
However, now valgrind gets confused: It sees overlapping mallocs() (the smaller
VALGRIND_MALLOCLIKE_BLOCKS are within the large chunks allocated with malloc()).
I'm now struggling with the instrumentation in our allocator but I can't get it
to work.
The error reports I get are just plain wrong: It says stuff like:
2019-08-06 00:57:20: ==30298== Invalid read of size 1
2019-08-06 00:57:20: ==30298== at 0x4059CF: main (valgrindTest.c:126)
2019-08-06 00:57:20: ==30298== Address 0x5e43878 is 72 bytes inside a block of
size 65,536 alloc'd
2019-08-06 00:57:20: ==30298== at 0x4C29DDB: malloc (vg_replace_malloc.c:299)
2019-08-06 00:57:20: ==30298== by 0x42DE98: mal_own_sbrk (al_alloc.c:4251)
2019-08-06 00:57:20: ==30298== by 0x42E7E5: mal_inc_space (al_alloc.c:4442)
2019-08-06 00:57:20: ==30298== by 0x4290E3: _mal_allocater (al_alloc.c:1915)
2019-08-06 00:57:20: ==30298== by 0x428235: mal_allocater_c (al_alloc.c:1608)
2019-08-06 00:57:20: ==30298== by 0x426C10: vmal_reserve_id (al_alloc.c:1131)
2019-08-06 00:57:20: ==30298== by 0x42690B: mal_reserve_id (al_alloc.c:999)
2019-08-06 00:57:20: ==30298== by 0x405495: main (valgrindTest.c:46)
So the offending byte is always in one of the "outer" malloced block of 64KB,
which is not what I want.
The stack is that of the allocator itself, also not what I want (the function
is still called mal_own_sbrk, but that is a misnomer now).
Another example:
==16897== Uninitialised value was created by a stack allocation
==16897== at 0x492748: evt_get_3glLong_event (evt_fun.c:388)
==16897==
The memory in question here is allocated using our allocator (and not on the
stack, so the reports is just wrong).
Secondly, the rest of call stack is missing. Seems valgrind is confused here.
I tried to lie to valgrind by using VALGRIND_FREELIKE_BLOCK immediately after
the malloc() that replaces sbrk(). No joy, it dumps core on me.
I tried to find a way to tell valgrind that it should close its eyes for a
moment while doing the low-level malloc(), but can't find a way to accomplish
that.
So I ask the collected wisdom of this mailing list: If I have a custom
allocator that uses malloc() to get large chunks and then doles out smaller
chunks to the application, how do I make that work with valgrind memcheck so
it sees only the allocations performed by the "outer" allocator and not the
inner one?
Thank you in advance,
Ruurd Beerstra.
Ruurd Beerstra, Principal Software Engineer
mobile: +31 622427478
ruurd.beers...@infor.com<mailto:ruurd.beers...@infor.com> |
http://www.infor.com<http://www.infor.com/>
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
