On 06/01/2016, Marshall Lochbaum wrote:
> Do you know whether what I want to do is possible with Valgrind, or are
> you just offering generic advice? Neither of the freelist options
> (freelist-vol and freelist-big-blocks) seem related, and indeed,
> changing them doesn't affect Valgrind's output on either your test
> program or J. I'm well aware that if I read all of Valgrind's source
> code I will eventually determine whether it has the option that I want,
> but that is a tall order just to be able to use the program.
>
>>From my perspective I have attempted to use Valgrind as intended, and it
> fails to provide the single most important piece of information for
> diagnosing a use-after-free error. I'm having difficulty understanding
> why anyone would even find the current output useful--it simply states
> that the offending block was allocated from the memory pool. The actual
> information is clearly accessible to Valgrind, and it refuses to show
> it! Even if this is only the default behavior, it strikes me as
> completely insane.
>
> Marshall
Valgrind (memcheck) works very well and does provide the information you seek
(in this case, the traceback at free() for the use-after-free error),
IF you do not use a custom pool allocator. When you use a custom pool
allocator, then the allocator must cooperate with memcheck for best results,
and even then the results might not be 100% equivalent.
Support for custom pool allocators is a newer feature whose implementation
might be incomplete. Or, the lack of traceback at free() for use-after-free
with a custom pool allocator might be a bug: submit a bug report
with a small test case that reproduces the behavior you dislike.
At the lowest level of VALGRIND_MEMPOOL_ALLOC, the cooperation
is not as good as that provided by VALGRIND_MALLOCLIKE_BLOCK.
So you might try using VALGRIND_MALLOCLIKE_BLOCK; but note that
the "red" zones introduce some overhead that requires thoughtful usage.
You might also try the variations of the --keep-stacktraces parameter.
Some explanation appears in valgrind.h. This is the top-level #include
that must be used to define VALGRIND_MEMPOOL_* macros, and it is reasonable
to expect that demanding users should have read and tried to understand it.
===== valgrind.h [excerpt; see the file for more]
/* Several Valgrind tools (Memcheck, Massif, Helgrind, DRD) rely on knowing
when heap blocks are allocated in order to give accurate results. This
happens automatically for the standard allocator functions such as
malloc(), calloc(), realloc(), memalign(), new, new[], free(), delete,
delete[], etc.
But if your program uses a custom allocator, this doesn't automatically
happen, and Valgrind will not do as well. ...
=====
It seems to me that users of a custom pool allocator should appreciate
that memcheck integrates as well as it does. After that, a pool allocator
that has good usability will have an easy mechanism for reverting
to ordinary malloc+free, for which memcheck provides excellent diagnosis.
------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
