valgrind: useful memory checker

valgrind: useful memory checker

[Felix Rosencrantz]

There is a new memory debugger available for Linux x86. According to the
web page(http://developer.kde.org/~sewardj/)  it can track such things as:

	- Use of uninitialised memory 
	- Reading/writing memory after it has been free'd 
	- Reading/writing off the end of malloc'd blocks 
	- Reading/writing inappropriate areas on the stack 
	- Memory leaks -- where pointers to malloc'd blocks are lost forever 
	- Passing of uninitialised and/or unaddressable memory to system calls 
	- Mismatched use of malloc/new/new [] vs free/delete/delete [] 

It is used as an aid to debug memory problems with KDE.  This useful
tool is written by Julian Seward.  It's very easy to start using.

I tried using it with Z-shell.  But initially there were some
problems, but Julian was able to fix these.   One of the problems
was that zsh calls malloc() during signal handlers.  Which Julian
pointed out is not a particularly safe thing to do....  (I figure
Bart or others might comment about this.)

Though, the latest version of valgrind in CVS seems to work with
ZSH.

Attached is a completion function for valgrind.  I'm not sure which
directory to place it in, possibly RedHat or Unix, though it is
intended to work with Linux x86.

Also, I ran valgrind on zsh interactively for a little bit, did
some completions and found a couple leaks.  Of course, adding valgrind
to the automated tests would be quite useful.

-FR.
==3725== 80 bytes in 1 blocks are definitely lost in loss record 45 of 136
==3725==    at 0x808C516: zalloc (in /bin/linux/zsh-020416d/bin/zsh)
==3725==    by 0x80A3010: patcompile (in /bin/linux/zsh-020416d/bin/zsh)
==3725==    by 0x413C4011: bin_zstyle (in
/bin/linux/zsh-020416d/lib/zsh/4.1.0-dev-4-020416/zsh/zutil.so)
==3725==    by 0x8052425: execbuiltin (in /bin/linux/zsh-020416d/bin/zsh)
==3725==    by 0x8067E93: execcmd (in /bin/linux/zsh-020416d/bin/zsh)
==3725==    by 0x806484B: execpline2 (in /bin/linux/zsh-020416d/bin/zsh)
==3725==    by 0x8063DDF: execpline (in /bin/linux/zsh-020416d/bin/zsh)
==3725==    by 0x80637D3: execlist (in /bin/linux/zsh-020416d/bin/zsh)
==3725== 
==3725== 132 bytes in 33 blocks are definitely lost in loss record 62 of 136
==3725==    at 0x808C516: zalloc (in /bin/linux/zsh-020416d/bin/zsh)
==3725==    by 0x80B9DE2: zarrdup (in /bin/linux/zsh-020416d/bin/zsh)
==3725==    by 0x411EC6D4: comp_wrapper (in
/bin/linux/zsh-020416d/lib/zsh/4.1.0-dev-4-020416/zsh/complete.so)
==3725==    by 0x806AB53: runshfunc (in /bin/linux/zsh-020416d/bin/zsh)
==3725==    by 0x806A973: doshfunc (in /bin/linux/zsh-020416d/bin/zsh)
==3725==    by 0x806A33C: execshfunc (in /bin/linux/zsh-020416d/bin/zsh)
==3725==    by 0x8067E09: execcmd (in /bin/linux/zsh-020416d/bin/zsh)
==3725==    by 0x806484B: execpline2 (in /bin/linux/zsh-020416d/bin/zsh)
==3725== 

#compdef valgrind 
#Generated by
#   simple2long.xsl
#   args.xsl
#   For details see:
#       http://www.geocities.com/f_rosencrantz/xml_completion.htm

 local context state line
           typeset -A opt_args
	_arguments   \
		'--help[show this message]' \
		'--version[show version]' \
		'(--quiet)-q[run silently; only print error msgs]' \
		'(-q)--quiet[run silently; only print error msgs]' \
		'(--verbose)-v[be more verbose, incl counts of errors]' \
		'(-v)--verbose[be more verbose, incl counts of errors]' \
		'--gdb-attach=-:start GDB when errors detected? [no]:(no yes)' \
		'--demangle=-:automatically demangle C++ names? [yes]:(no yes)' \
		'--num-callers=-:show  callers in stack traces [4]:->number' \
		'--partial-loads-ok=-:too hard to explain here; see manual [yes]:(no yes)' \
		'--leak-check=-:search for memory leaks at exit? [no]:(no yes)' \
		'--leak-resolution=-:amount of bt merging in leak check [low]:(low med high)'
\
		'--show-reachable=-:show reachable blocks in leak check? [no]:(no yes)' \
		'--sloppy-malloc=-:round malloc sizes to next word? [no]:(no yes)' \
		'--trace-children=-:Valgrind-ise child processes? [no]:(no yes)' \
		'--logfile-fd=-:file descriptor for messages [2=stderr]:->number' \
		'--freelist-vol=-:volume of freed blocks queue [1000000]:->number' \
		'--workaround-gcc296-bugs=-:self explanatory [no]:(no yes)' \
		'--suppressions=-:suppress errors described in suppressions file :_files' \
		'--client-perms=-:handle client VG_MAKE_* requests? [no]:(no yes)' \
		"--check-addrVs=-:experimental lighterweight checking? [yes] yes ==
Valgrind's original behaviour:(no yes)" \
		'--sanity-level=-:level of sanity checking to do [1]:->number' \
		'--single-step=-:translate each instr separately? [no]:(no yes)' \
		'--optimise=-:improve intermediate code? [yes]:(no yes)' \
		'--instrument=-:actually do memory checks? [yes]:(no yes)' \
		'--cleanup=-:improve after instrumentation? [yes]:(no yes)' \
		'--trace-syscalls=-:show all system calls? [no]:(no yes)' \
		'--trace-signals=-:show signal handling details? [no]:(no yes)' \
		'--trace-symtab=-:show symbol table details? [no]:(no yes)' \
		'--trace-malloc=-:show client malloc details? [no]:(no yes)' \
		'--trace-sched=-:show thread scheduler details? [no]:(no yes)' \
		'--trace-pthread=-:show pthread event details? [no]:(no yes)' \
		'--stop-after=-:switch to real CPU after executing  basic blocks
[infinity]:->number' \
		"--dump-error=-:show translation for basic block associated with 'th error
context [0=don't show any]:->number" \
		'1: :_command_names -e' \
		'*:: :_normal' \
           && return 0
            
case $state in
  "number");;
esac


__________________________________________________
Do You Yahoo!?
Yahoo! Games - play chess, backgammon, pool and more
http://games.yahoo.com/

Re: valgrind: useful memory checker

[Bart Schaefer]

On Mon, 22 Apr 2002, Felix Rosencrantz wrote:

> One of the problems was that zsh calls malloc() during signal handlers.
> Which Julian pointed out is not a particularly safe thing to do....  (I
> figure Bart or others might comment about this.)

It's "not particularly safe" only if you don't know what you're doing.

We went to some trouble a while ago to assure that signals are blocked
while zsh is performing other memory allocations, so that we don't have
re-entry problems with calling malloc() from inside the handlers when they
do get called.

Re: valgrind: useful memory checker

[Julian Seward]

> > One of the problems was that zsh calls malloc() during signal handlers.
> > Which Julian pointed out is not a particularly safe thing to do....  (I
> > figure Bart or others might comment about this.)
> 
> It's "not particularly safe" only if you don't know what you're doing.
> 
> We went to some trouble a while ago to assure that signals are blocked
> while zsh is performing other memory allocations, so that we don't have
> re-entry problems with calling malloc() from inside the handlers when they
> do get called.

Yes, it's fairer to say that until recently valgrind had a really nasty
hack to do with delivering signals to processes blocked in system calls,
which apparently zsh does.  So valgrind was somewhat limited in what 
it could do safely in this situation.

Valgrind snapshots >= 20020420 have completely new signal simulation
stuff, and all those limitations have gone away.

> Also, I ran valgrind on zsh interactively for a little bit, did
> some completions and found a couple leaks.  Of course, adding valgrind
> to the automated tests would be quite useful.

Valgrind's -s flag makes it completely silent apart from reporting errors.
This was added specifically to help people who want to add it to automated
regression test systems.  You might find it useful.

J

Re: valgrind: useful memory checker

[Sven Wischnowsky]

Felix Rosencrantz wrote:

> ...
> 
> Also, I ran valgrind on zsh interactively for a little bit, did
> some completions and found a couple leaks.  Of course, adding valgrind
> to the automated tests would be quite useful.
> 
> -FR.
> ==3725== 80 bytes in 1 blocks are definitely lost in loss record 45 of 136
> ==3725==    at 0x808C516: zalloc (in /bin/linux/zsh-020416d/bin/zsh)
> ==3725==    by 0x80A3010: patcompile (in /bin/linux/zsh-020416d/bin/zsh)
> ==3725==    by 0x413C4011: bin_zstyle (in
> /bin/linux/zsh-020416d/lib/zsh/4.1.0-dev-4-020416/zsh/zutil.so)
> ==3725==    by 0x8052425: execbuiltin (in /bin/linux/zsh-020416d/bin/zsh)
> ==3725==    by 0x8067E93: execcmd (in /bin/linux/zsh-020416d/bin/zsh)
> ==3725==    by 0x806484B: execpline2 (in /bin/linux/zsh-020416d/bin/zsh)
> ==3725==    by 0x8063DDF: execpline (in /bin/linux/zsh-020416d/bin/zsh)
> ==3725==    by 0x80637D3: execlist (in /bin/linux/zsh-020416d/bin/zsh)

Do you set the same style for the same pattern twice?

> ==3725== 132 bytes in 33 blocks are definitely lost in loss record 62 of 136
> ==3725==    at 0x808C516: zalloc (in /bin/linux/zsh-020416d/bin/zsh)
> ==3725==    by 0x80B9DE2: zarrdup (in /bin/linux/zsh-020416d/bin/zsh)
> ==3725==    by 0x411EC6D4: comp_wrapper (in
> /bin/linux/zsh-020416d/lib/zsh/4.1.0-dev-4-020416/zsh/complete.so)
> ==3725==    by 0x806AB53: runshfunc (in /bin/linux/zsh-020416d/bin/zsh)
> ==3725==    by 0x806A973: doshfunc (in /bin/linux/zsh-020416d/bin/zsh)
> ==3725==    by 0x806A33C: execshfunc (in /bin/linux/zsh-020416d/bin/zsh)
> ==3725==    by 0x8067E09: execcmd (in /bin/linux/zsh-020416d/bin/zsh)
> ==3725==    by 0x806484B: execpline2 (in /bin/linux/zsh-020416d/bin/zsh)
> ==3725== 

These are 33 times a char ** to a NULL pointer. The copied compredirs
array.


Bye
  Sven

Index: Src/Modules/zutil.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Modules/zutil.c,v
retrieving revision 1.9
diff -u -r1.9 zutil.c
--- Src/Modules/zutil.c	9 Jul 2001 16:05:14 -0000	1.9
+++ Src/Modules/zutil.c	24 Apr 2002 07:56:12 -0000
@@ -132,6 +132,7 @@
 		freearray(p->vals);
 	    if (p->eval)
 		freeeprog(p->eval);
+            freepatprog(p->prog);
 	    p->vals = zarrdup(vals);
 	    p->eval = eprog;
 
Index: Src/Zle/complete.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/complete.c,v
retrieving revision 1.20
diff -u -r1.20 complete.c
--- Src/Zle/complete.c	1 Mar 2002 10:42:02 -0000	1.20
+++ Src/Zle/complete.c	24 Apr 2002 07:56:12 -0000
@@ -1320,6 +1320,7 @@
 	    zsfree(oqs);
 	    zsfree(oaq);
 	    freearray(owords);
+	    freearray(oredirs);
 	}
 	zsfree(comprestore);
 	comprestore = orest;

-- 
Sven Wischnowsky                          wischnow@berkom.de

Re: valgrind: useful memory checker

[Felix Rosencrantz]

--- Sven Wischnowsky <wischnow@berkom.de> wrote:
> Do you set the same style for the same pattern twice?
Not sure.  Will have to check.

I've re-run valgrind again with the latest patches.  There seem to be some
problems related to these changes.  The results are sent under separate cover.

-FR.

__________________________________________________
Do You Yahoo!?
Yahoo! Games - play chess, backgammon, pool and more
http://games.yahoo.com/

Re: valgrind: useful memory checker

[Felix Rosencrantz]

--- Felix Rosencrantz <f_rosencrantz@yahoo.com> wrote:
> --- Sven Wischnowsky <wischnow@berkom.de> wrote:
> > Do you set the same style for the same pattern twice?
> Not sure.  Will have to check.

I turns out that was the case.  I tried sourcing my .zstyle file again and was
able to generate one leak per duplicate zstyle. 

-FR.


__________________________________________________
Do You Yahoo!?
Yahoo! Games - play chess, backgammon, pool and more
http://games.yahoo.com/