zsh-workers
 help / color / mirror / code / Atom feed
* Re: PATCH (4.0.x, 4.1.x): Re: Core dump bug in ZSH version 3.0.7
@ 2001-11-15  8:13 Wischnowsky, Sven
  0 siblings, 0 replies; 4+ messages in thread
From: Wischnowsky, Sven @ 2001-11-15  8:13 UTC (permalink / raw)
  To: zsh-workers


Bart wrote:

> On Nov 14,  9:57am, Wischnowsky, Sven wrote:
> } 
> } [ Hi, folks! ]
> 
> [ Hi, Sven! ]
> 
> } My change put that cleanup-loop in a separate function, 
> though, and made
> } that function be called anywhere where we call bld_eprog() 
> (if (success)),
> } just to make sure...
> 
> I'll hold off committing mine, then.

Well, here is mine. As I said, I currently don't have the possibility
to commit it even if everyone accepts this patch.

Bye
  Sven

diff -ur ../oz/Src/parse.c ./Src/parse.c
--- ../oz/Src/parse.c	Tue Nov 13 21:51:59 2001
+++ ./Src/parse.c	Tue Nov 13 22:14:14 2001
@@ -420,6 +420,18 @@
     return (!p || !p->prog || *p->prog == WCB_END());
 }
 
+static void
+clear_hdocs()
+{
+    struct heredocs *p, *n;
+
+    for (p = hdocs; p; p = n) {
+        n = p->next;
+        zfree(p, sizeof(struct heredocs));
+    }
+    hdocs = NULL;
+}
+
 /*
  * event	: ENDINPUT
  *			| SEPER
@@ -435,7 +447,12 @@
     aliasspaceflag = 0;
     yylex();
     init_parse();
-    return ((par_event()) ? bld_eprog() : NULL);
+
+    if (!par_event()) {
+        clear_hdocs();
+        return NULL;
+    }
+    return bld_eprog();
 }
 
 /**/
@@ -509,6 +526,7 @@
     init_parse();
     par_list(&c);
     if (tok != ENDINPUT) {
+        clear_hdocs();
 	tok = LEXERR;
 	yyerror(0);
 	return NULL;
@@ -522,9 +540,10 @@
 {
     init_parse();
 
-    if (!par_cond())
+    if (!par_cond()) {
+        clear_hdocs();
 	return NULL;
-
+    }
     return bld_eprog();
 }
 


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: PATCH (4.0.x, 4.1.x): Re: Core dump bug in ZSH version 3.0.7
  2001-11-14  8:57 Wischnowsky, Sven
@ 2001-11-15  5:38 ` Bart Schaefer
  0 siblings, 0 replies; 4+ messages in thread
From: Bart Schaefer @ 2001-11-15  5:38 UTC (permalink / raw)
  To: zsh-workers

On Nov 14,  9:57am, Wischnowsky, Sven wrote:
} 
} [ Hi, folks! ]

[ Hi, Sven! ]

} My change put that cleanup-loop in a separate function, though, and made
} that function be called anywhere where we call bld_eprog() (if (success)),
} just to make sure...

I'll hold off committing mine, then.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: PATCH (4.0.x, 4.1.x): Re: Core dump bug in ZSH version 3.0.7
@ 2001-11-14  8:57 Wischnowsky, Sven
  2001-11-15  5:38 ` Bart Schaefer
  0 siblings, 1 reply; 4+ messages in thread
From: Wischnowsky, Sven @ 2001-11-14  8:57 UTC (permalink / raw)
  To: zsh-workers


[ Hi, folks! ]

Bart wrote:

> On Nov 12,  6:59pm, Bart Schaefer wrote:
> } Subject: Re: Core dump bug in ZSH version 3.0.7
> }
> } It doesn't crash 4.0.x/4.1.x, but it does get into a rather 
> strange state,
> } trying to read a here-document whose start/end string is a 
> single space,
> } which of course is impossible (so you're trapped in the 
> here-document until
> } you interrupt somehow).
> } 
> } zagzig% mask = (1 << string.atoi(sys.argv[1])) - 1
> } zsh: parse error near `)'
> 
> At this point we've parsed this as the command "mask" with 
> arguments "="
> and "(1" and with here-document ending at 
> "string.atoi(sys.argv[1])"; the
> parse error is at the second parenthesis.
> 
> However, when zsh bailed out with the parse error, it failed 
> to pop the
> pending here-document off the queue of such documents. 

Exactly.

> So 
> then when it
> begins parsing this:
> 
> } zagzig% key = string.atoi(sys.argv[2])
> } heredoc>  

(Actually, just hitting Return shows the bug - the prompt changes from normal
to `heredoc', whew.)

>  	    return 0;
>  	}
>  	yyerror(1);
> +	while (hdocs) {
> +	    struct heredocs *next = hdocs->next;
> +	    zfree(hdocs, sizeof(struct heredocs));
> +	    hdocs = next;
> +	}
>  	herrflush();
>  	if (noerrs != 2)
>  	    errflag = 1;

I built a similar patch yesterday evening, but then forgot to bring it
with me today. (I'm terribly net-handicapped at the moment, because I'm
behind a fiendish firewall in a disgusting Windows-net here and don't
have my Unix-box yet, so I couldn't commit the change myself anyway.)

My change put that cleanup-loop in a separate function, though, and made
that function be called anywhere where we call bld_eprog() (if (success)),
just to make sure...

Bye
  Sven

P.S.: My other computer will be put into a different net here so I hope to
      be able to participate again when it arrives. Also, my E-mail address
      will be wischnow@berkom.de, not the one above (the berkom-address is
      already functional, forwarded telekom.de).


^ permalink raw reply	[flat|nested] 4+ messages in thread

* PATCH (4.0.x, 4.1.x): Re: Core dump bug in ZSH version 3.0.7
  2001-11-12 18:59 ` Bart Schaefer
@ 2001-11-13 18:21   ` Bart Schaefer
  0 siblings, 0 replies; 4+ messages in thread
From: Bart Schaefer @ 2001-11-13 18:21 UTC (permalink / raw)
  To: Carl Feynman, zsh-workers

On Nov 12,  6:59pm, Bart Schaefer wrote:
} Subject: Re: Core dump bug in ZSH version 3.0.7
}
} It doesn't crash 4.0.x/4.1.x, but it does get into a rather strange state,
} trying to read a here-document whose start/end string is a single space,
} which of course is impossible (so you're trapped in the here-document until
} you interrupt somehow).
} 
} zagzig% mask = (1 << string.atoi(sys.argv[1])) - 1
} zsh: parse error near `)'

At this point we've parsed this as the command "mask" with arguments "="
and "(1" and with here-document ending at "string.atoi(sys.argv[1])"; the
parse error is at the second parenthesis.

However, when zsh bailed out with the parse error, it failed to pop the
pending here-document off the queue of such documents.  So then when it
begins parsing this:

} zagzig% key = string.atoi(sys.argv[2])
} heredoc>  

Zsh now believes it is accepting input for the here-document started at
the previous command line.  4.0+ doesn't crash because it re-uses the
memory at which the here-document's name is pointing, so the document
merely seems to have a bogus name; 3.0.x crashes because the name pointer
in the here-document structure has become garbage.

The solution seems to be the following; I haven't checked whether it will
apply directly to 3.0.x, as this patch is based on 4.1.0-dev-2:

Index: Src/parse.c
===================================================================
--- Src/parse.c	2001/09/05 15:22:33	1.10
+++ Src/parse.c	2001/11/13 18:10:10
@@ -481,6 +481,11 @@
 	    return 0;
 	}
 	yyerror(1);
+	while (hdocs) {
+	    struct heredocs *next = hdocs->next;
+	    zfree(hdocs, sizeof(struct heredocs));
+	    hdocs = next;
+	}
 	herrflush();
 	if (noerrs != 2)
 	    errflag = 1;

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2001-11-15  8:14 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-11-15  8:13 PATCH (4.0.x, 4.1.x): Re: Core dump bug in ZSH version 3.0.7 Wischnowsky, Sven
  -- strict thread matches above, loose matches on Subject: below --
2001-11-14  8:57 Wischnowsky, Sven
2001-11-15  5:38 ` Bart Schaefer
2001-11-12 18:28 Carl Feynman
2001-11-12 18:59 ` Bart Schaefer
2001-11-13 18:21   ` PATCH (4.0.x, 4.1.x): " Bart Schaefer

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).