On Tue, 2013-05-14 at 04:28 +0200, Roland Mainz wrote:
> On Thu, Apr 25, 2013 at 1:42 PM, Sebastian Feld
> <sebastian.n.f...@gmail.com> wrote:
> > On Wed, Apr 24, 2013 at 11:10 PM, Roland Mainz <roland.ma...@nrubsig.org>
> > wrote:
> >> On Wed, Apr 24, 2013 at 10:14 PM, Roland Mainz <roland.ma...@nrubsig.org>
> >> wrote:
> >>> On Wed, Apr 24, 2013 at 12:45 AM, John Reiser <jrei...@bitwagon.com>
> >>> wrote:
> >> $ 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 think it would not be very difficult to extend the command line option
--soname-synonyms=syn1=pattern1,syn2=pattern2,... synonym soname
specify patterns for function wrapping or replacement.
To use a non-libc malloc library that is
in the main exe: --soname-synonyms=somalloc=NONE
in libxyzzy.so: --soname-synonyms=somalloc=libxyzzy.so
to support also to give synonym for the "function" part of a redirection.
Now that I understand better all this area, it should be relatively
easy to allow to give synonyms for any (existing) redirection
(library part or function part).
In other words, to make -soname-synonyms "generic".
> >
> > 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.
However, the impact of this part is not as easy.
This implies to change the basic way the malloc interception is done,
by adding an additional "grouping" parameter, and store this in each
memory "chunk" managed by memcheck.
More impact on memory, and on the interface between the core and
the tools replacing the malloc, and a lot more difficult to make
"generic".
I suspect this will imply also some possibly heavy changes to
the "core" redirection logic.
> Uhm... was there any feedback yet for that idea ?
Some feedback above :).
Philippe
------------------------------------------------------------------------------
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
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
