From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-workers-return-16245-mason-zsh=primenet.com.au@sunsite.dk>
Received: (qmail 2332 invoked from network); 14 Nov 2001 08:57:54 -0000
Received: from ns2.primenet.com.au (HELO primenet.com.au) (?a0tJlDNoSyU+zVHFCD6rXyTJ5lTCwQcF?@203.24.36.3)
  by ns1.primenet.com.au with SMTP; 14 Nov 2001 08:57:54 -0000
Received: (qmail 4593 invoked from network); 14 Nov 2001 08:57:52 -0000
Received: from sunsite.dk (130.225.247.90)
  by proxy.melb.primenet.com.au with SMTP; 14 Nov 2001 08:57:52 -0000
Received: (qmail 19191 invoked by alias); 14 Nov 2001 08:57:46 -0000
Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm
Precedence: bulk
X-No-Archive: yes
X-Seq: 16245
Received: (qmail 19179 invoked from network); 14 Nov 2001 08:57:45 -0000
Message-Id: <7D865FB0D0A1D5118B6E000347055BBB14847A@G9JNT.mgb01.telekom.de>
From: "Wischnowsky, Sven" <Sven.Wischnowsky@t-systems.de>
To: zsh-workers@sunsite.dk
Subject: Re: PATCH (4.0.x, 4.1.x): Re: Core dump bug in ZSH version 3.0.7
Date: Wed, 14 Nov 2001 09:57:26 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain


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