periodic in 4.0.2

periodic in 4.0.2

[Allan Poindexter]

I have periodic set to something like this:

periodic () { source ~/.zsh.aliases }

In 4.0.2 this segfaults zsh when CR is typed following the first automatic
execution of periodic.  It works if periodic is invoked from the command line.
It works if periodic doesn't source a file.  The problem only appears when
sourcing files within periodic when periodic is being executed after the
PERIOD interval before the prompt.  (Well, at least that is the only thing I
have found to trigger it so far.)

Re: periodic in 4.0.2

[Bart Schaefer]

On Sep 7,  5:43pm, Allan Poindexter wrote:
> Subject: periodic in 4.0.2
> I have periodic set to something like this:
> 
> periodic () { source ~/.zsh.aliases }
> 
> In 4.0.2 this segfaults zsh when CR is typed following the first automatic
> execution of periodic.

Same bug as was patched in zsh-workers/15707.

Peter, are you back yet?  We should release 4.0.3.

Re: periodic in 4.0.2

[Allan Poindexter]

 Allan> I have periodic set to something like this:

 Allan> periodic () { source ~/.zsh.aliases }

 Allan> In 4.0.2 this segfaults zsh when CR is typed following the first
 Allan> automatic execution of periodic.

 Bart> Same bug as was patched in zsh-workers/15707.

 Bart> Peter, are you back yet?  We should release 4.0.3.

D'oh!  I hadn't had a chance to read the list in a while so I searched for
periodic in the archives to see if it had been reported.  I should have
guessed that precmd might have the same problem.

segfaults in 4.0.2

[Clint Adams]

> Same bug as was patched in zsh-workers/15707.
> 
> Peter, are you back yet?  We should release 4.0.3.

It also seems that something like

coproc || echo test

will cause a segfault.

Re: segfaults in 4.0.2

[Bart Schaefer]

On Sep 8,  1:59am, Clint Adams wrote:
}
} It also seems that something like
} 
} coproc || echo test
} 
} will cause a segfault.

Doesn't for me, neither in 4.0.1 nor in the current 4.1.x CVS snapshot (I
don't have an actual 4.0.2 handy).

Can you provide more details?

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

Re: segfaults in 4.0.2

[Clint Adams]

> Doesn't for me, neither in 4.0.1 nor in the current 4.1.x CVS snapshot (I
> don't have an actual 4.0.2 handy).
> 
> Can you provide more details?

Yes.  It doesn't happen with -f.
I can reproduce it this way:

zsh -f
autoload -U promptinit ; promptinit
prompt ${${(z):-adam1 adam2 bigfade clint elite2}[RANDOM%5]}
coproc || echo test

Of the prompts I tried, only ``bart'' didn't facilitate a segfault.
I can't narrow down what the prompts do as causative.

Here's a backtrace:

#0  0x4011b31f in strlen () from /lib/libc.so.6
#1  0x80b0dda in taddstr (s=0x5cdabea8 <Address 0x5cdabea8 out of bounds>)
    at text.c:60
#2  0x80b156e in gettext2 (state=0xbffffcac) at text.c:322
#3  0x80b10bd in getjobtext (prog=0x40016168, c=0x40016188) at text.c:160
#4  0x8078ae2 in loop (toplevel=1, justonce=0) at init.c:153
#5  0x807b582 in zsh_main (argc=1, argv=0xbffffdcc) at init.c:1214
#6  0x8051826 in main (argc=1, argv=0xbffffdcc) at ./main.c:37

Re: segfaults in 4.0.2

[Bart Schaefer]

On Sep 8, 11:34am, Clint Adams wrote:
}
} Yes.  It doesn't happen with -f.
} I can reproduce it this way:
} 
} prompt ${${(z):-adam1 adam2 bigfade clint elite2}[RANDOM%5]}
} coproc || echo test

Hmm, the `pc' field in the wordcode state struct is messed up:

Breakpoint 1, ecgetstr (s=0xbffff6bc, dup=0, tok=0x0)
    at ../../zsh-4.0/Src/parse.c:2102
2102        wordcode c = *s->pc++;
(gdb) n
2105        if (c == 6 || c == 7)
(gdb) p s->strs
$6 = 0x4011b190 "echo"
(gdb) p c
$7 = 1074856044

This causes ecgetstr() to return a garbage pointer.

We may have to wait for Sven to get back ...

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

Re: segfaults in 4.0.2

[Sven Wischnowsky]

[Hi, I'm back.]

Bart Schaefer wrote:

> On Sep 8, 11:34am, Clint Adams wrote:
> }
> } Yes.  It doesn't happen with -f.
> } I can reproduce it this way:
> } 
> } prompt ${${(z):-adam1 adam2 bigfade clint elite2}[RANDOM%5]}
> } coproc || echo test
> 
> Hmm, the `pc' field in the wordcode state struct is messed up:
> 
> Breakpoint 1, ecgetstr (s=0xbffff6bc, dup=0, tok=0x0)
>     at ../../zsh-4.0/Src/parse.c:2102
> 2102        wordcode c = *s->pc++;
> (gdb) n
> 2105        if (c == 6 || c == 7)
> (gdb) p s->strs
> $6 = 0x4011b190 "echo"
> (gdb) p c
> $7 = 1074856044
> 
> This causes ecgetstr() to return a garbage pointer.

I couldn't make it crash, but I can see the problem: it's that empty
sublist, which the code in text.c wasn't able to handle (it made it
effectively look one code too far ahead).  The code in exec.c has an
extra test for that, so I've just (more or less) copied it from there.


Bye
  Sven

Index: Src/text.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/text.c,v
retrieving revision 1.7
diff -u -r1.7 text.c
--- Src/text.c	2001/08/16 08:48:27	1.7
+++ Src/text.c	2001/09/25 12:01:50
@@ -274,10 +274,12 @@
 	    break;
 	case WC_SUBLIST:
 	    if (!s) {
+                if (wc_code(*state->pc) != WC_PIPE)
+                    stack = 1;
 		if (WC_SUBLIST_FLAGS(code) & WC_SUBLIST_NOT)
-		    taddstr("! ");
+		    taddstr(stack ? "!" : "! ");
 		if (WC_SUBLIST_FLAGS(code) & WC_SUBLIST_COPROC)
-		    taddstr("coproc ");
+		    taddstr(stack ? "coproc" : "coproc ");
 		s = tpush(code, (WC_SUBLIST_TYPE(code) == WC_SUBLIST_END));
 	    } else {
 		if (!(stack = (WC_SUBLIST_TYPE(code) == WC_SUBLIST_END))) {

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

Re: segfaults in 4.0.2

[Sven Wischnowsky]

I wrote:

> ...
> 
> I couldn't make it crash, but I can see the problem: it's that empty
> sublist, which the code in text.c wasn't able to handle (it made it
> effectively look one code too far ahead).  The code in exec.c has an
> extra test for that, so I've just (more or less) copied it from there.

Ouch, no, that was a bit too simple because of possible simplified
sublists.


Bye
  Sven

Index: Src/text.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/text.c,v
retrieving revision 1.8
diff -u -r1.8 text.c
--- Src/text.c	2001/09/25 12:10:05	1.8
+++ Src/text.c	2001/09/25 12:44:13
@@ -274,8 +274,9 @@
 	    break;
 	case WC_SUBLIST:
 	    if (!s) {
-                if (wc_code(*state->pc) != WC_PIPE)
-                    stack = 1;
+                if (!(WC_SUBLIST_FLAGS(code) & WC_SUBLIST_SIMPLE) &&
+                    wc_code(*state->pc) != WC_PIPE)
+                    stack = -1;
 		if (WC_SUBLIST_FLAGS(code) & WC_SUBLIST_NOT)
 		    taddstr(stack ? "!" : "! ");
 		if (WC_SUBLIST_FLAGS(code) & WC_SUBLIST_COPROC)
@@ -293,7 +294,7 @@
 			taddstr("coproc ");
 		}
 	    }
-	    if (!stack && (WC_SUBLIST_FLAGS(s->code) & WC_SUBLIST_SIMPLE))
+	    if (stack < 1 && (WC_SUBLIST_FLAGS(s->code) & WC_SUBLIST_SIMPLE))
 		state->pc++;
 	    break;
 	case WC_PIPE:

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

Re: periodic in 4.0.2

[Peter Stephenson]

Bart Schaefer wrote:
> Peter, are you back yet?  We should release 4.0.3.

Yes, but this definitely needs to be based on the stable branch.  There are
too many feature changes on the other branch already for it to be
suitable as the basis for a patch release.

Needless to say, I haven't been keeping proper track of bits that need to
go on the 4.0 branch, though I've tried to apply my own changes to both
branches where necessary.

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


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