Memory leaks found by valgrind

Memory leaks found by valgrind

[Felix Rosencrantz]

I ran valgrind with a recent version of zsh from cvs (about a week old, so the
line numbers don't much the code today).  And got the following memory leaks. 
The shell ran for a few days, though it didn't get heavy use.  It would be
great if other folks could run with valgrind, purify, or any other code
scouring tools.


659 bytes in 4 blocks are definitely lost in loss record 8 of 13
   at 0x40165A60: malloc (vg_clientfuncs.c:100)
   by 0x8086055: zalloc (mem.c:490)
   by 0x80E2122: calclist (compresult.c:1583)
   by 0x80E8750: complistmatches (complist.c:1607)


(This one seems to have come from children processes.)
464 bytes in 4 blocks are definitely lost in loss record 5 of 11
   at 0x40165A60: malloc (vg_clientfuncs.c:100)
   by 0x80861D5: zcalloc (mem.c:508)
   by 0x807983C: addproc (jobs.c:832)
   by 0x805D6BE: execpline (exec.c:1057)

-FR.

ps valgrind can be found at http://developer.kde.org/~sewardj/ useful for linux
i86 folkds.

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

Memory leaks found by valgrind (try2)

[Felix Rosencrantz]

I ran valgrind with a version of zsh from around Feb 10th.
Below are the memory leaks.  The shell ran for a few days, and I gave it more
usage.

(This one is new.)
1026 bytes in 1 blocks are possibly lost in loss record 10 of 14
   at 0x40166069: realloc (vg_clientfuncs.c:273)
   by 0x81104DE: sizeline (zle_utils.c:70)
   by 0x8110506: spaceinline (zle_utils.c:81)
   by 0x810196B: doinsert (zle_misc.c:49)
   by 0x8101A87: selfinsert (zle_misc.c:71)
   by 0x80FFEA3: execzlefunc (zle_main.c:862)

This one I believe is a repeat.
324 bytes in 5 blocks are definitely lost in loss record 7 of 14
   at 0x40165A60: malloc (vg_clientfuncs.c:100)
   by 0x808617D: zalloc (mem.c:490)
   by 0x80E2312: calclist (compresult.c:1590)
   by 0x80E8940: complistmatches (complist.c:1607)
   by 0x808A5E6: runhookdef (module.c:1865)
   by 0x80E3F1B: list_matches (compresult.c:2167)

(I think this is more a termcap bug, but I get it often enough, that I thought
I would send it.)
2130 bytes in 50 blocks are definitely lost in loss record 12 of 14
   at 0x40165A60: malloc (vg_clientfuncs.c:100)
   by 0x40238EFE: (within /lib/libtermcap.so.2.0.8)
   by 0x4023988B: (within /lib/libtermcap.so.2.0.8)
   by 0x40239A13: (within /lib/libtermcap.so.2.0.8)
   by 0x40239AA6: tgetent (in /lib/libtermcap.so.2.0.8)
   by 0x80749C8: init_term (init.c:557)


-FR.

__________________________________________________
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day
http://shopping.yahoo.com

Re: Memory leaks found by valgrind

[Peter Stephenson]

Felix Rosencrantz wrote:
> 659 bytes in 4 blocks are definitely lost in loss record 8 of 13
>    at 0x40165A60: malloc (vg_clientfuncs.c:100)
>    by 0x8086055: zalloc (mem.c:490)
>    by 0x80E2122: calclist (compresult.c:1583)
>    by 0x80E8750: complistmatches (complist.c:1607)

Most of the amatches linked list is on the heap (according to one
comment), but the widths element of each structure is dynamically
allocated.  It's hard to see when it should be freed.  It's currently
only allocated and freed in one function (calclist()); maybe that
function simply needs more logic, but I can't be sure.

> (This one seems to have come from children processes.)
> 464 bytes in 4 blocks are definitely lost in loss record 5 of 11
>    at 0x40165A60: malloc (vg_clientfuncs.c:100)
>    by 0x80861D5: zcalloc (mem.c:508)
>    by 0x807983C: addproc (jobs.c:832)
>    by 0x805D6BE: execpline (exec.c:1057)

I presume this is because when we enter a subshell we don't completely
delete the stuff in the job table, just delete a few bits of it and zero
the rest out.  I have a patch for this at home, but it's not a major
problem.  The only case I can see where it would become one was a
long-lived shell instance recursively starting a subshell while the
original shell exited, which isn't a normal use.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 692070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

Re: Memory leaks found by valgrind

[Felix Rosencrantz]

Sorry I haven't had much of a chance to run valgrind with the latest patches,
particularly the one from Peter.  (Thanks Peter, though.)

I noticed that the termcap leak occurs even if I do what I consider to be
a no-op: TERM=$TERM
Doing that repeatedly could leak a bit of memory.  To me, it seems like a
pretty minor issue.

The only new leak I found was the following.   This I believe is related
to replace-string command.  When I tried that widget, I would get more
leaks.  (I haven't tried using other recent features/changes.)
 62 bytes in 62 blocks are definitely lost in loss record 5 of 13
    at 0x40165A60: malloc (vg_clientfuncs.c:100)
    by 0x8086275: zalloc (mem.c:490)
    by 0x810536C: set_prepost (zle_params.c:485)
    by 0x810541E: set_postdisplay (zle_params.c:515)
    by 0x808F7F4: setstrvalue (params.c:1608)
    by 0x8090BAC: assignsparam (params.c:1994)
    by 0x805F0A6: addvars (exec.c:1598)
    by 0x805CDC9: execsimple (exec.c:756)

-FR.


__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/

Re: Memory leaks found by valgrind

[Peter Stephenson]

Felix Rosencrantz wrote:
> The only new leak I found was the following.   This I believe is related
> to replace-string command.  When I tried that widget, I would get more
> leaks.  (I haven't tried using other recent features/changes.)
>  62 bytes in 62 blocks are definitely lost in loss record 5 of 13
>     at 0x40165A60: malloc (vg_clientfuncs.c:100)
>     by 0x8086275: zalloc (mem.c:490)
>     by 0x810536C: set_prepost (zle_params.c:485)
>     by 0x810541E: set_postdisplay (zle_params.c:515)
>     by 0x808F7F4: setstrvalue (params.c:1608)
>     by 0x8090BAC: assignsparam (params.c:1994)
>     by 0x805F0A6: addvars (exec.c:1598)
>     by 0x805CDC9: execsimple (exec.c:756)

This could be the following, which needs patching anyway.

Index: Src/Zle/zle_params.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/zle_params.c,v
retrieving revision 1.8
diff -u -r1.8 zle_params.c
--- Src/Zle/zle_params.c	27 Jan 2003 14:55:02 -0000	1.8
+++ Src/Zle/zle_params.c	5 Mar 2003 13:58:09 -0000
@@ -482,8 +482,10 @@
     }
     if (x) {
 	unmetafy(x, lenvar);
-	*textvar = (unsigned char *)zalloc(*lenvar);
-	memcpy((char *)*textvar, x, *lenvar);
+	if (*lenvar) {
+	    *textvar = (unsigned char *)zalloc(*lenvar);
+	    memcpy((char *)*textvar, x, *lenvar);
+	}
 	free(x);
     }
 }

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 692070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************