|
From: ольга к. <olg...@gm...> - 2012-04-03 20:07:05
|
How do I use custom memory allocators with valgrind? We'd like to use
the memory allocators from AT&T libast but also like to use valgrind
for (automated) error checking. Is there any howto document how to do
this?
Olga
--
, _ _ ,
{ \/`o;====- Olga Kryzhanovska -====;o`\/ }
.----'-/`-/ olg...@gm... \-`\-'----.
`'-..-| / http://twitter.com/fleyta \ |-..-'`
/\/\ Solaris/BSD//C/C++ programmer /\/\
`--` `--`
|
|
From: Philippe W. <phi...@sk...> - 2012-04-03 20:22:17
|
On Tue, 2012-04-03 at 22:06 +0200, ольга крыжановская wrote: > How do I use custom memory allocators with valgrind? We'd like to use > the memory allocators from AT&T libast but also like to use valgrind > for (automated) error checking. Is there any howto document how to do > this? > > Olga http://www.valgrind.org/docs/manual/mc-manual.html#mc-manual.mempools describes what Valgrind provides for "real" custom allocators. Now, if libast provides a set of malloc/free/... compatible functions, then you should rather modify Valgrind to intercept these replacement. See bug https://bugs.kde.org/show_bug.cgi?id=219156 for a patch implementing replacements for tcmalloc library. Philippe |
|
From: ольга к. <olg...@gm...> - 2012-04-03 20:40:45
|
Philippe, libast provides both malloc replacement and a complex allocation system based on io streams, e.g.sort of stdio with disciplines on steroids where even string buffers, or lists and trees of (nested) string buffers, can be a io stream or memory buffer. Is it really wise to modify valgrind just to intercept the custom malloc/calloc/memalign/free implementation? It sounds like an over kill and might be problematic because we would have to wait until each Linux vendor has updated to the new valgrind version. Olga 2012/4/3 Philippe Waroquiers <phi...@sk...>: > On Tue, 2012-04-03 at 22:06 +0200, ольга крыжановская wrote: >> How do I use custom memory allocators with valgrind? We'd like to use >> the memory allocators from AT&T libast but also like to use valgrind >> for (automated) error checking. Is there any howto document how to do >> this? >> >> Olga > > http://www.valgrind.org/docs/manual/mc-manual.html#mc-manual.mempools > describes what Valgrind provides for "real" custom allocators. > > Now, if libast provides a set of malloc/free/... compatible functions, > then you should rather modify Valgrind to intercept these replacement. > See bug https://bugs.kde.org/show_bug.cgi?id=219156 > for a patch implementing replacements for tcmalloc library. > > Philippe > > -- , _ _ , { \/`o;====- Olga Kryzhanovska -====;o`\/ } .----'-/`-/ olg...@gm... \-`\-'----. `'-..-| / http://twitter.com/fleyta \ |-..-'` /\/\ Solaris/BSD//C/C++ programmer /\/\ `--` `--` |
|
From: Philippe W. <phi...@sk...> - 2012-04-03 20:59:19
|
On Tue, 2012-04-03 at 22:40 +0200, ольга крыжановская wrote: > Philippe, libast provides both malloc replacement and a complex > allocation system based on io streams, e.g.sort of stdio with > disciplines on steroids where even string buffers, or lists and trees > of (nested) string buffers, can be a io stream or memory buffer. > > Is it really wise to modify valgrind just to intercept the custom > malloc/calloc/memalign/free implementation? It sounds like an over > kill and might be problematic because we would have to wait until each > Linux vendor has updated to the new valgrind version. If valgrind is not informed that libast has malloc/free/... replacements, then many/most valgrind tools are less functional (e.g. memcheck will not detect leaks). So, if your application is using the malloc/free/... of libast rather than the "standard" malloc/free, I think it is a good idea to have the replacements done. Now, I do not understand why you would have to wait until each Linux vendor has updated to the new valgrind version. Just do the changes, and have your valgrind compiled in a corner :). (in addition, I am not sure a libast replacement patch for Valgrind would be committed). For what concerns the complex allocation system: if this system is doing a direct usage of libast malloc/free/..., then the replacements above will be good enough. If this complex allocation system is malloc-ing or mmap-ing a big block, and then does its own "small blocks" from these big blocks, then you have to add Valgrind mempool client requests in the libast code to have Valgrind understanding this complex allocation system. Philippe |