[ast-developers] valgrind 3.8.1 patch to recognise libast allocator...

[Roland Mainz]

Hi!

----

Attached (as "valgrind381_libast_allocator001.diff.txt") is a patch
for valgrind 3.8.1 which enables valgrind (again) to recognise the
libast memory allocator (long ago it worked out-of-the-box but somehow
it got broken).

The basic idea of the fix is to teach valgrind that the matching
memory allocation/deallocation functions are prefixed with |_ast_*()|.

Usage:
-- snip --
wget 'http://valgrind.org/downloads/valgrind-3.8.1.tar.bz2'
bzcat < 'valgrind-3.8.1.tar.bz2' | tar -xf -
cd valgrind-3.8.1
patch -p1 < "valgrind381_libast_allocator001.diff.txt"
configure --prefix=$HOME/vg 2>&1 | tee -a buildlog.log
make all | tee -a buildlog.log
make install | tee -a buildlog.log
-- snip --
... there should then be a new version of "valgrind" installed in
$HOME/vg/bin/valgrind which can instrument/check libast-based
applications (erm... it's 2:52am here... I only checked binaries with
libast staically linked... I didn't check binaries with a dynamically
linked libast.so.1 yet... ;-/ )

Good news: valgrind now works again for libast-based applications
Bad news: there are *MANY* valgrind hits in ast-ksh.2013-05-03 (I'll
file follow-up bugs) ... ;-(

----

Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL [phone]
(;O/ \/ \O;)
-------------- next part --------------
diff -r -u valgrind-3.8.1_original/configure valgrind-3.8.1/configure
--- valgrind-3.8.1_original/configure 2012-09-18 21:19:23.000000000 +0200
+++ valgrind-3.8.1/configure 2013-05-17 02:11:18.875880006 +0200
@@ -6594,7 +6594,7 @@
DEFAULT_SUPP="glibc-2.34567-NPTL-helgrind.supp ${DEFAULT_SUPP}"
DEFAULT_SUPP="glibc-2.X-drd.supp ${DEFAULT_SUPP}"
;;
- 2.16)
+ 2.16|2.17)
{ $as_echo "$as_me:${as_lineno-$LINENO}: result: 2.16 family" >&5
$as_echo "2.16 family" >&6; }

diff -r -u valgrind-3.8.1_original/coregrind/m_replacemalloc/vg_replace_malloc.c valgrind-3.8.1/coregrind/m_replacemalloc/vg_replace_malloc.c
--- valgrind-3.8.1_original/coregrind/m_replacemalloc/vg_replace_malloc.c 2012-08-17 08:59:55.000000000 +0200
+++ valgrind-3.8.1/coregrind/m_replacemalloc/vg_replace_malloc.c 2013-05-17 02:40:10.456307573 +0200
@@ -997,6 +997,16 @@
#endif


+ALLOC_or_NULL(NONE, _ast_malloc, malloc);
+FREE(NONE, _ast_free, free);
+FREE(NONE, _ast_cfree, free);
+CALLOC(NONE, _ast_calloc);
+REALLOC(NONE, _ast_realloc);
+MEMALIGN(NONE, _ast_memalign);
+POSIX_MEMALIGN(NONE, _ast_posix_memalign);
+VALLOC(NONE, _ast_valloc);
+MALLINFO(NONE, _ast_mallinfo);
+
/*------------------ Darwin zone stuff ------------------*/

#if defined(VGO_darwin)

[Irek Szczesniak]

Post by Roland Mainz
Hi!
----
Attached (as "valgrind381_libast_allocator001.diff.txt") is a patch
for valgrind 3.8.1 which enables valgrind (again) to recognise the
libast memory allocator (long ago it worked out-of-the-box but somehow
it got broken).
The basic idea of the fix is to teach valgrind that the matching
memory allocation/deallocation functions are prefixed with |_ast_*()|.

Just curious - how long did it take to figure that valgrind is broken
for AST and to make the fix?

Irek

[Roland Mainz]

Post by Irek Szczesniak

Post by Roland Mainz
Attached (as "valgrind381_libast_allocator001.diff.txt") is a patch
for valgrind 3.8.1 which enables valgrind (again) to recognise the
libast memory allocator (long ago it worked out-of-the-box but somehow
it got broken).
The basic idea of the fix is to teach valgrind that the matching
memory allocation/deallocation functions are prefixed with |_ast_*()|.

Just curious - how long did it take to figure that valgrind is broken

I know that since a month for so because some things which didn't work
should've triggered valgrind...

Post by Irek Szczesniak
for AST and to make the fix?

The prototype fix mainly needed a lot of digging+research (and
gnaw'ing off my fingernails to figure out how valgrind works... maybe
eight manhours or something like that...
... the research digged out some issues with valgrind which have to be
addressed from their side in the future:
1. valgrind needs support for multiple, independent memory allocators
operating in the same process. Right now it operates in "one allocator
to rule them all"-mode and doesn't properly detect issues when memory
obtained via |_chicken_malloc()| is passed to |_fish_free()| (instead
of |_chicken_free()|)). This is *lots* of work and may require some
restructuring how "valgrind"'s "memcheck" tool works (that's around
2-3 manmonths of work... without support for "nested" memory pools).
2. We need the ability to configure "valgrind" to recognise
alternative names for |malloc()|, |realloc()|, |free()|,
|posix_memalign()| via command line options or an options file
(interestingly Google concurrently hit the same issue with similar
solutions - see http://code.google.com/p/valgrind-variant/).

I'm going to discuss that with the "valgrind" people when I have time...

----

Bye,
Roland

[Roland Mainz]

Post by Roland Mainz

Post by Irek Szczesniak

Post by Roland Mainz
Attached (as "valgrind381_libast_allocator001.diff.txt") is a patch
for valgrind 3.8.1 which enables valgrind (again) to recognise the
libast memory allocator (long ago it worked out-of-the-box but somehow
it got broken).
The basic idea of the fix is to teach valgrind that the matching
memory allocation/deallocation functions are prefixed with |_ast_*()|.

Just curious - how long did it take to figure that valgrind is broken

I know that since a month for so because some things which didn't work
should've triggered valgrind...

Post by Irek Szczesniak
for AST and to make the fix?

The prototype fix mainly needed a lot of digging+research (and
gnaw'ing off my fingernails to figure out how valgrind works... maybe
eight manhours or something like that...
... the research digged out some issues with valgrind which have to be
1. valgrind needs support for multiple, independent memory allocators
operating in the same process. Right now it operates in "one allocator
to rule them all"-mode and doesn't properly detect issues when memory
obtained via |_chicken_malloc()| is passed to |_fish_free()| (instead
of |_chicken_free()|)). This is *lots* of work and may require some
restructuring how "valgrind"'s "memcheck" tool works (that's around
2-3 manmonths of work... without support for "nested" memory pools).
2. We need the ability to configure "valgrind" to recognise
alternative names for |malloc()|, |realloc()|, |free()|,
|posix_memalign()| via command line options or an options file
(interestingly Google concurrently hit the same issue with similar
solutions - see http://code.google.com/p/valgrind-variant/).
I'm going to discuss that with the "valgrind" people when I have time...

Erm... Glen/Irek: Do you have any feedback on the valgrind patch ?

----

Bye,
Roland