>>>> I tried to work around the issues with the API provided in >>>> <valgrind/valgrind.h> ... but it seems this doesn't detect any >>>> read-from-unallocated etc. or even the plain double-free situations >>>> (patch below) ... erm... is the API around >>>> |VALGRIND_MALLOCLIKE_BLOCK()| know to work in valgrind-3.8.1 ?
If you have a small reproducible test case that fails, then file a bug report. Imprecise moaning gets ignored immediately. Mailing list discussions get forgotten, even those on [valgrind-developers]. [[snip]] >>> ... aaand more digging: I found >>> http://code.google.com/p/valgrind-variant/source/browse/trunk/valgrind/coregrind/m_replacemalloc/vg_replace_malloc.c#1175 >>> which seems to be from one of the valgrind forks... what about >>> talking-up that idea and provide a command line option called >>> --allocator-sym-redirect which works like passing down a small list of >>> symbol mappings to instruct valgrind that it should monitor some extra >>> allocators. >>> >>> Example: >>> $ valgrind >>> "--allocator-sym-redirect=sh_malloc=malloc,sh_free=free,sh_calloc=calloc" >>> ... # would instruct valgrind to take function |sh_malloc()| as an >>> alternative |malloc(), |sh_free()| as alternative |free()| version >>> etc. etc. >>> >>> The only issue is that if multiple allocators are active within a >>> single process we may need some kind of "grouping" to explain valgrind >>> that memory allocated by |sh_malloc()| can not be freed by |tcfree()| >>> or |_ast_free()| ... maybe it could be done using '{'- and '}'-pairs, >>> e.g. $ valgrind >>> "--allocator-sym-redirect={sh_malloc=malloc,sh_free=free,sh_calloc=calloc},{_ast_malloc=malloc,_ast_free=free,_ast_calloc=calloc}" >>> ... # >> >> The idea of (finally!) providing such an option sounds like a very >> good idea. Until now the only way to probe python and bash4 via >> valgrind is to poke in the valgrind sources (which should never >> happen). >> >> I also think the idea to let valgrind detect mixing of different >> allocators is a very valuable feature since this has been a source of >> more and more bugs. Usually happens in complex projects with use many >> different shared libraries, all with their own memory allocators. Carefully design the feature that you want, both syntax and semantics. Cover all the interactions with the existing machinery of memcheck. Enter your "Request For Enhancement (RFE)" as a bug report. "Sell" it to the developers of memcheck. Explain the problems with the existing implementation, the benefits of the new feature that you want, how the new feature would work, etc. Provide several literal examples (no hand waving, no meta-syntax, no free variables.) Defend against all known and imagined objections: imprecise specification, not enough practical benefit, hard to use correctly, too hard to implement, too costly to execute, impossible to maintain, cannot be documented, ... . > > Uhm... was there any feedback yet for that idea ? A serious proposal merits the work required to sell it to the developers, and must be recorded using the bug reporting machinery. -- ------------------------------------------------------------------------------ AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d _______________________________________________ Valgrind-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/valgrind-users
