zsh-workers
 help / color / mirror / code / Atom feed
From: Sven Wischnowsky <wischnow@informatik.hu-berlin.de>
To: zsh-workers@sunsite.auc.dk
Subject: Re: PATCH: Small memory leak and doc fix
Date: Mon, 5 Jun 2000 09:55:47 +0200 (MET DST)	[thread overview]
Message-ID: <200006050755.JAA03367@beta.informatik.hu-berlin.de> (raw)
In-Reply-To: Felix Rosencrantz's message of Fri, 2 Jun 2000 20:23:59 -0700 (PDT)


Felix Rosencrantz wrote:

> Here's another memory leak fix along with a small doc fix.
> 
> There seems to be some situations when the following code will see
> uninitialized memory reads from the following stack:
> 	pattern_match  [compmatch.c:1035]
>         match_str      [compmatch.c:577]
>         comp_match     [compmatch.c:941]
>         addmatches     [compcore.c:1954]
>         bin_compadd    [complete.c:595]
> I haven't looked into this, so if more details are needed let me know.

Haven't had the time to look at this, but knowing the match specs used
would help.

> --- Sven Wischnowsky <wischnow@informatik.hu-berlin.de> wrote:
> >Hmm. Maybe we get this because some parameter setfn() neither uses nor 
> >frees the string it gets.
> I took a look at some of the memory that wasn't freed, and found one of the
> strings had a value that only came out of the value of complist
> ("ambiguous packed rows").  So something that touches that value has a problem.
> Maybe a parameter operator.

I found that at the weekend already: it's $compstate[list]. And then
there was another one in $commands.

Does that fix the problems with addvars()?

> >I can't see where this comes from. mkautofn() creates the
> >autofn-program wich is then freed in loadautofn() (or
> >freeshfuncnode(), with ksh-autoloading).
> >
> >All these autofn-progs won't be freed at the end, though (together
> >with many other things).
> 
> I can see these errors even before the shell exits.  The memory checker
> will only list a memory leak if there are no pointers in memory to a memory
> block.  We are probably losing the pointer to the memory from buitlin.c:2162.

Ouch. Right. `pats' should point to the same memory as `prog' because
that's what's used for freeing.

Bye
 Sven

Index: Src/builtin.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/builtin.c,v
retrieving revision 1.20
diff -u -r1.20 builtin.c
--- Src/builtin.c	2000/05/27 08:31:32	1.20
+++ Src/builtin.c	2000/06/05 07:55:01
@@ -2162,7 +2162,7 @@
     p->strs = NULL;
     p->shf = shf;
     p->npats = 0;
-    p->pats = NULL;
+    p->pats = (Patprog *) p->prog;
     p->flags = EF_REAL;
     p->dump = NULL;
 
Index: Src/Modules/parameter.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Modules/parameter.c,v
retrieving revision 1.8
diff -u -r1.8 parameter.c
--- Src/Modules/parameter.c	2000/06/02 01:54:16	1.8
+++ Src/Modules/parameter.c	2000/06/05 07:55:01
@@ -192,9 +192,10 @@
 static void
 setpmcommand(Param pm, char *value)
 {
-    if (isset(RESTRICTED))
+    if (isset(RESTRICTED)) {
 	zwarn("restricted: %s", value, 0);
-    else {
+	zsfree(value);
+    } else {
 	Cmdnam cn = zcalloc(sizeof(*cn));
 
 	cn->flags = HASHED;
Index: Src/Zle/compresult.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/compresult.c,v
retrieving revision 1.18
diff -u -r1.18 compresult.c
--- Src/Zle/compresult.c	2000/05/31 09:56:12	1.18
+++ Src/Zle/compresult.c	2000/06/05 07:55:02
@@ -1168,7 +1168,7 @@
 comp_list(char *v)
 {
     zsfree(complist);
-    complist = ztrdup(v);
+    complist = v;
 
     onlyexpl = (v ? ((strstr(v, "expl") ? 1 : 0) |
 		     (strstr(v, "messages") ? 2 : 0)) : 0);

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de


             reply	other threads:[~2000-06-05  7:56 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-06-05  7:55 Sven Wischnowsky [this message]
  -- strict thread matches above, loose matches on Subject: below --
2000-06-09  5:26 Felix Rosencrantz
2000-06-08  9:20 Sven Wischnowsky
2000-06-08  2:50 Felix Rosencrantz
2000-06-07 13:23 Sven Wischnowsky
2000-06-06  5:31 Felix Rosencrantz
2000-06-03  3:23 Felix Rosencrantz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200006050755.JAA03367@beta.informatik.hu-berlin.de \
    --to=wischnow@informatik.hu-berlin.de \
    --cc=zsh-workers@sunsite.auc.dk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).