strange behavior

strange behavior

[Vincent Lefevre]

With the svnwrapper script below, I got after rebooting the machine:

ypig:~/wd> up
At revision 40202.
zsh: exit 141
ypig:~/wd[PIPE]>

where "up" does "svnwrapper up". I don't see how this could be
possible, as the only svn output is "At revision 40202." to stdout
(nothing to stderr here, so that brpipe remains unset).

svnwrapper script:

#!/usr/bin/env zsh

filter()
{
  unset brpipe
  while true
  do
    unset line timeout
    while read -r $timeout -k -u 0 ch
    do
      line="$line$ch"
      [[ $ch = $'\012' ]] && break
      timeout=(-t 0.1)
    done
    case $line in
      svnwrapper:term$'\012')
        break ;;
      *Broken\ pipe$'\012') brpipe=1 ;;
      ?*) printf "%s" "$line" >&2 ;;
      *) break ;;  # empty line (end of file) - parent has died?
    esac
  done
  # The "sleep 5" is there to avoid a rare race condition (it occurred
  # once): make sure the parent process receives the PIPE signal before
  # the filter process terminates (which can yield a SIGPIPE in svn).
  [[ -z $brpipe ]] || { kill -PIPE $$; sleep 5 }
}

{ svn "$@"; st=$?; echo "svnwrapper:term" >&2 } 2>>(filter)
exit $st

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Re: strange behavior

[Vincent Lefevre]

On 2010-11-02 13:09:43 +0100, Vincent Lefevre wrote:
> With the svnwrapper script below, I got after rebooting the machine:
> 
> ypig:~/wd> up
> At revision 40202.
> zsh: exit 141
> ypig:~/wd[PIPE]>
> 
> where "up" does "svnwrapper up". I don't see how this could be
> possible, as the only svn output is "At revision 40202." to stdout
> (nothing to stderr here, so that brpipe remains unset).
[...]

This has just happened again. This time, the machine hadn't been
rebooted (but there has been a lot of disk activity before that).

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Re: strange behavior

[Bart Schaefer]

On Nov 15,  5:32pm, Vincent Lefevre wrote:
}
} > ypig:~/wd> up
} > At revision 40202.
} > zsh: exit 141
} > ypig:~/wd[PIPE]>
} 
} This has just happened again. This time, the machine hadn't been
} rebooted (but there has been a lot of disk activity before that).

It appears to me that it must be the case that
	svn "$@"
is exiting with status 141, rather than that the filter function is
killing its parent with a PIPE signal.

That in turn must be happening "inside" svn somewhere.

Re: strange behavior

[Vincent Lefevre]

On 2010-11-15 09:24:38 -0800, Bart Schaefer wrote:
> On Nov 15,  5:32pm, Vincent Lefevre wrote:
> }
> } > ypig:~/wd> up
> } > At revision 40202.
> } > zsh: exit 141
> } > ypig:~/wd[PIPE]>
> } 
> } This has just happened again. This time, the machine hadn't been
> } rebooted (but there has been a lot of disk activity before that).
> 
> It appears to me that it must be the case that
> 	svn "$@"
> is exiting with status 141, rather than that the filter function is
> killing its parent with a PIPE signal.

I don't think this is possible as when svn receives a PIPE signal,
it outputs "svn: Write error: Broken pipe" and exits with status 1.
But I've added some code to check that status 141 is not possible.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Re: strange behavior

[Vincent Lefevre]

On 2010-11-16 04:10:23 +0100, Vincent Lefevre wrote:
> On 2010-11-15 09:24:38 -0800, Bart Schaefer wrote:
> > On Nov 15,  5:32pm, Vincent Lefevre wrote:
> > }
> > } > ypig:~/wd> up
> > } > At revision 40202.
> > } > zsh: exit 141
> > } > ypig:~/wd[PIPE]>
> > } 
> > } This has just happened again. This time, the machine hadn't been
> > } rebooted (but there has been a lot of disk activity before that).
> > 
> > It appears to me that it must be the case that
> > 	svn "$@"
> > is exiting with status 141, rather than that the filter function is
> > killing its parent with a PIPE signal.
> 
> I don't think this is possible as when svn receives a PIPE signal,
> it outputs "svn: Write error: Broken pipe" and exits with status 1.
> But I've added some code to check that status 141 is not possible.

While the problem described above was not rare, since I modified
the script in the following way (two months ago), I can no longer
see the problem.

-{ svn "$@"; st=$?; echo "svnwrapper:term" >&2 } 2>>(filter)
+{
+  svn "$@"
+  st=$?
+  [[ $st -eq 141 ]] && echo "Exit with status 141!" >&2
+  echo "svnwrapper:term" >&2
+} 2>>(filter)

So, either the problem has been fixed somewhere or it can no longer
be seen due to the change in my script. In the latter case, it is
probably a bug in zsh. I'm going to revert this change and see if
I can see the problem again...

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Re: strange behavior

[Bart Schaefer]

On Jan 28,  3:44pm, Vincent Lefevre wrote:
} Subject: Re: strange behavior
}
} On 2010-11-16 04:10:23 +0100, Vincent Lefevre wrote:
} > On 2010-11-15 09:24:38 -0800, Bart Schaefer wrote:
} > > 
} > > It appears to me that it must be the case that
} > > 	svn "$@"
} > > is exiting with status 141, rather than that the filter function is
} > > killing its parent with a PIPE signal.
} 
} While the problem described above was not rare, since I modified
} the script in the following way (two months ago), I can no longer
} see the problem.
} 
} -{ svn "$@"; st=$?; echo "svnwrapper:term" >&2 } 2>>(filter)
} +{
} +  svn "$@"
} +  st=$?
} +  [[ $st -eq 141 ]] && echo "Exit with status 141!" >&2
} +  echo "svnwrapper:term" >&2
} +} 2>>(filter)

I forget whether we covered this before, but does {svn "$@"} ever
fork as part of its execution?

There has to be some kind of race condition here.  2>>(filter) runs
filter in the background, so if something behind svn also runs as an
separate process, it could be possible for the filter to exit and
close it's stdin (thereby closing everything else's stdder) before
operating-system-level exit-time buffer-flushing has finished.
 
} So, either the problem has been fixed somewhere or it can no longer
} be seen due to the change in my script. In the latter case, it is
} probably a bug in zsh. I'm going to revert this change and see if
} I can see the problem again...

Hmm, another thought ... maybe the "zsh: exit 141" is coming from
the shell's exit-time handling of the "filter" program, rather than
from svn.  I've lost enough context here that I don't recall whether
that was previously ruled out too.

Re: strange behavior

[Vincent Lefevre]

On 2011-01-28 07:49:15 -0800, Bart Schaefer wrote:
> I forget whether we covered this before, but does {svn "$@"} ever
> fork as part of its execution?

Yes (for SSH connection, and the ssh script can start a SSH master
connection, which will still run in background after svn terminates,
and that's why I needed the svnwrapper:term trick in my script).

> There has to be some kind of race condition here.  2>>(filter) runs
> filter in the background, so if something behind svn also runs as an
> separate process, it could be possible for the filter to exit and
> close it's stdin (thereby closing everything else's stdder) before
> operating-system-level exit-time buffer-flushing has finished.

Yes, this happens, but I don't see why this could make the script
terminate with a broken pipe. I recall the whole script:

filter()
{
  unset brpipe
  while true
  do
    unset line timeout
    while read -r $timeout -k -u 0 ch
    do
      line="$line$ch"
      [[ $ch = $'\012' ]] && break
      timeout=(-t 0.1)
    done
    case $line in
      svnwrapper:term$'\012')
        break ;;
      *Broken\ pipe$'\012') brpipe=1 ;;
      ?*) printf "%s" "$line" >&2 ;;
      *) break ;;  # empty line (end of file) - parent has died?
    esac
  done
  # The "sleep 5" is there to avoid a rare race condition (it occurred
  # once): make sure the parent process receives the PIPE signal before
  # the filter process terminates (which can yield a SIGPIPE in svn).
  [[ -z $brpipe ]] || { kill -PIPE $$; sleep 5 }
}

{ svn "$@"; st=$?; echo "svnwrapper:term" >&2 } 2>>(filter)
exit $st

Because of the "while true" loop, filter should still run after svn
terminates.

Note that when I obtained the "zsh: exit 141", the svn output wasn't
redirected, so that a "Broken pipe" message from svn was not possible.

> Hmm, another thought ... maybe the "zsh: exit 141" is coming from
> the shell's exit-time handling of the "filter" program, rather than
> from svn.  I've lost enough context here that I don't recall whether
> that was previously ruled out too.

What do you mean here?

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Re: strange behavior

[Bart Schaefer]

On Jan 30,  1:37am, Vincent Lefevre wrote:
} Subject: Re: strange behavior
}
} On 2011-01-28 07:49:15 -0800, Bart Schaefer wrote:
} > There has to be some kind of race condition here.  2>>(filter) runs
} > filter in the background, so if something behind svn also runs as an
} > separate process, it could be possible for the filter to exit and
} > close it's stdin (thereby closing everything else's stdder) before
} > operating-system-level exit-time buffer-flushing has finished.
} 
} Yes, this happens, but I don't see why this could make the script
} terminate with a broken pipe.

Possible epiphany:  zsh prints "zsh: exit 141" like that only if the
exit status came from a builtin or shell function (Src/exec.c).  For
all external commands or subshells it appends the jobtext after the
status number (Src/jobs.c).  Those are the only PRINTEXITVALUE cases.

Thus the exit value of 141 must be coming from one of these places:

(1) "read" builtin in the inner loop of "filter"
(2) "printf" in the ?* branch of the case in "filter"
(3) "echo" in the { ... } expression

I can't imagine how "read" could return 141.

For the { echo } statement, I get "zsh: broken pipe" every way I try
to make it fail, before zsh ever gets around to PRINTEXITVALUE.

That leaves "printf" ...

Which at first let me to wonder if what's happening is that the inner
while loop is failing to consume the entire svnwrapper:term$'\012' in
a single pass around the outer loop, e.g. that the -t option you're
adding after reading the first character causes read to time out on
some calls instead of reading the next character.  But that implies
that the stderr of "filter" is getting closed somehow, and I can't
think of a way that would happen.

So I'm still stuck.  What we need is an "strace -ff -o ..." or the
equivalent to tell which process is printing that, but tracing may resolve
the race condition and prevent the error.

} Note that when I obtained the "zsh: exit 141", the svn output wasn't
} redirected, so that a "Broken pipe" message from svn was not possible.

I don't understand what "wasn't redirected" means.  Stderr is always
redirected; "Broken pipe" could occur if svn prints something to
stderr after 2>>(filter) has exited.  I still can't figure out how
to tie that to "zsh: exit 141" given the constraints above, though.

} > Hmm, another thought ... maybe the "zsh: exit 141" is coming from
} > the shell's exit-time handling of the "filter" program, rather than
} > from svn.  I've lost enough context here that I don't recall whether
} > that was previously ruled out too.
} 
} What do you mean here?

I meant that 2>>(...) is handled specially.  Because "filter" is a
shell function, it runs in a subshell which might have inherited the
printexitvalue setopt from its parent.  When filter exits inside the
subshell, perhaps the subshell is printing "exit 141" before it also
exits.  *That* could correspond to printf barfing, but what would be
closing the stderr of the command substitution?

Re: strange behavior

[Vincent Lefevre]

On 2011-01-30 14:25:40 -0800, Bart Schaefer wrote:
> So I'm still stuck.  What we need is an "strace -ff -o ..." or the
> equivalent to tell which process is printing that, but tracing may resolve
> the race condition and prevent the error.

Yes, and I don't know how to reproduce the error.

> } Note that when I obtained the "zsh: exit 141", the svn output wasn't
> } redirected, so that a "Broken pipe" message from svn was not possible.
> 
> I don't understand what "wasn't redirected" means.

I meant the script output. The error occurred when I ran "svnwrapper up"
(no redirections, contrary to "svnwrapper log | head").

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Re: strange behavior

[Vincent Lefevre]

On 2011-01-30 14:25:40 -0800, Bart Schaefer wrote:
> Possible epiphany:  zsh prints "zsh: exit 141" like that only if the
> exit status came from a builtin or shell function (Src/exec.c).  For
> all external commands or subshells it appends the jobtext after the
> status number (Src/jobs.c).  Those are the only PRINTEXITVALUE cases.
> 
> Thus the exit value of 141 must be coming from one of these places:
> 
> (1) "read" builtin in the inner loop of "filter"
> (2) "printf" in the ?* branch of the case in "filter"
> (3) "echo" in the { ... } expression

I can reproduce the SIGPIPE problem when resizing the terminal window
while the wrapper is being run. According to strace, it's (3).

> I can't imagine how "read" could return 141.
> 
> For the { echo } statement, I get "zsh: broken pipe" every way I try
> to make it fail, before zsh ever gets around to PRINTEXITVALUE.
> 
> That leaves "printf" ...
> 
> Which at first let me to wonder if what's happening is that the inner
> while loop is failing to consume the entire svnwrapper:term$'\012' in
> a single pass around the outer loop, e.g. that the -t option you're
> adding after reading the first character causes read to time out on
> some calls instead of reading the next character.  But that implies
> that the stderr of "filter" is getting closed somehow, and I can't
> think of a way that would happen.
> 
> So I'm still stuck. What we need is an "strace -ff -o ..." or the
> equivalent to tell which process is printing that, but tracing may
> resolve the race condition and prevent the error.

Here's the end of the strace output:

access("/home/vlefevre/bin/svnwrapper", F_OK) = 0
stat("/home/vlefevre/bin/svnwrapper", {st_mode=S_IFREG|0755, st_size=2027, ...}) = 0
open("/home/vlefevre/bin/svnwrapper", O_RDONLY|O_NOCTTY) = 3
fcntl(3, F_DUPFD, 10)                   = 11
close(3)                                = 0
fcntl(11, F_GETFL)                      = 0x8000 (flags O_RDONLY|O_LARGEFILE)
fstat(11, {st_mode=S_IFREG|0755, st_size=2027, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ffa4ad2c000
lseek(11, 0, SEEK_CUR)                  = 0
read(11, "#!/usr/bin/env zsh\n\n# svn wrappe"..., 4096) = 2027
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
pipe([3, 5])                            = 0
fcntl(3, F_DUPFD, 10)                   = 12
close(3)                                = 0
fcntl(5, F_DUPFD, 10)                   = 13
close(5)                                = 0
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7ffa4ad399d0) = 19270
close(12)                               = 0
fcntl(2, F_DUPFD, 10)                   = 12
close(2)                                = 0
dup2(13, 2)                             = 2
close(13)                               = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [CHLD], 8) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [CHLD], 8) = 0
pipe([3, 5])                            = 0
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7ffa4ad399d0) = 19271
close(5)                                = 0
read(3, "", 1)                          = 0
close(3)                                = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [CHLD], 8) = 0
rt_sigsuspend([INT])                    = ? ERESTARTNOHAND (To be restarted)
--- SIGCHLD (Child exited) @ 0 (0) ---
--- SIGWINCH (Window changed) @ 0 (0) ---
rt_sigprocmask(SIG_BLOCK, ~[RTMIN RT_1], [INT CHLD WINCH], 8) = 0
rt_sigprocmask(SIG_SETMASK, [INT CHLD WINCH], ~[KILL STOP RTMIN RT_1], 8) = 0
ioctl(10, TIOCGWINSZ, {ws_row=60, ws_col=85, ws_xpixel=523, ws_ypixel=784}) = 0
rt_sigreturn(0x1c)                      = 0
rt_sigprocmask(SIG_BLOCK, ~[RTMIN RT_1], [INT CHLD], 8) = 0
rt_sigprocmask(SIG_SETMASK, [INT CHLD], ~[KILL STOP RTMIN RT_1], 8) = 0
wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], WNOHANG|WSTOPPED|WCONTINUED, {ru_utime={0, 0}, ru_stime={0, 0}, ...}) = 19270
wait4(-1, 0x7ffff6dd97ec, WNOHANG|WSTOPPED|WCONTINUED, 0x7ffff6dd9740) = 0
rt_sigreturn(0xffffffff)                = -1 EINTR (Interrupted system call)
rt_sigprocmask(SIG_BLOCK, [CHLD], [CHLD], 8) = 0
rt_sigsuspend([INT])                    = ? ERESTARTNOHAND (To be restarted)
--- SIGCHLD (Child exited) @ 0 (0) ---
rt_sigprocmask(SIG_BLOCK, ~[RTMIN RT_1], [INT CHLD], 8) = 0
rt_sigprocmask(SIG_SETMASK, [INT CHLD], ~[KILL STOP RTMIN RT_1], 8) = 0
wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], WNOHANG|WSTOPPED|WCONTINUED, {ru_utime={0, 196012}, ru_stime={0, 204012}, ...}) = 19271
wait4(-1, 0x7ffff6dd97ec, WNOHANG|WSTOPPED|WCONTINUED, 0x7ffff6dd9740) = -1 ECHILD (No child processes)
rt_sigreturn(0xffffffff)                = -1 EINTR (Interrupted system call)
rt_sigprocmask(SIG_BLOCK, [CHLD], [CHLD], 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [CHLD], [CHLD], 8) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [CHLD], [CHLD], 8) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
dup(2)                                  = 3
fcntl(1, F_DUPFD, 10)                   = 13
close(1)                                = 0
dup2(3, 1)                              = 1
close(3)                                = 0
write(1, "svnwrapper:term\n", 16)       = -1 EPIPE (Broken pipe)
--- SIGPIPE (Broken pipe) @ 0 (0) ---
+++ killed by SIGPIPE +++

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Re: strange behavior

[Vincent Lefevre]

On 2011-04-11 16:26:18 +0200, Vincent Lefevre wrote:
> On 2011-01-30 14:25:40 -0800, Bart Schaefer wrote:
> > Possible epiphany:  zsh prints "zsh: exit 141" like that only if the
> > exit status came from a builtin or shell function (Src/exec.c).  For
> > all external commands or subshells it appends the jobtext after the
> > status number (Src/jobs.c).  Those are the only PRINTEXITVALUE cases.
> > 
> > Thus the exit value of 141 must be coming from one of these places:
> > 
> > (1) "read" builtin in the inner loop of "filter"
> > (2) "printf" in the ?* branch of the case in "filter"
> > (3) "echo" in the { ... } expression
> 
> I can reproduce the SIGPIPE problem when resizing the terminal window
> while the wrapper is being run. According to strace, it's (3).

and this is because the SIGWINCH seems to interrupt the "read"
(is it a bug?), so that

    while read -r $timeout -k -u 0 ch
    do
      line="$line$ch"
      [[ $ch = $'\012' ]] && break
      timeout=(-t 0.1)
    done

gives an empty string; hence the observed behavior.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Re: strange behavior

[Peter Stephenson]

On Mon, 11 Apr 2011 16:39:30 +0200
Vincent Lefevre <vincent@vinc17.org> wrote:
> and this is because the SIGWINCH seems to interrupt the "read"
> (is it a bug?), so that
> 
>     while read -r $timeout -k -u 0 ch
>     do
>       line="$line$ch"
>       [[ $ch = $'\012' ]] && break
>       timeout=(-t 0.1)
>     done
> 
> gives an empty string; hence the observed behavior.

Yes, we handle EINTR in most places and should do so here.  There are
lots of nasty special cases in bin_read(); I think this is this one.

Index: Src/builtin.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/builtin.c,v
retrieving revision 1.249
diff -p -u -r1.249 builtin.c
--- Src/builtin.c	4 Mar 2011 13:25:26 -0000	1.249
+++ Src/builtin.c	11 Apr 2011 15:13:19 -0000
@@ -5291,9 +5291,16 @@ bin_read(char *name, char **args, Option
 		    *bptr = readchar;
 		    val = 1;
 		    readchar = -1;
-		} else if ((val = read(readfd, bptr, nchars)) <= 0) {
-		    eof = 1;
-		    break;
+		} else {
+		    while ((val = read(readfd, bptr, nchars)) < 0) {
+			if (errno != EINTR ||
+			    errflag || retflag || breaks || contflag)
+			    break;
+		    }
+		    if (val <= 0) {
+			eof = 1;
+			break;
+		    }
 		}
 
 #ifdef MULTIBYTE_SUPPORT

-- 
Peter Stephenson <pws@csr.com>            Software Engineer
Tel: +44 (0)1223 692070                   Cambridge Silicon Radio Limited
Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK


Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom

Re: strange behavior

[Vincent Lefevre]

On 2011-04-11 16:15:27 +0100, Peter Stephenson wrote:
> On Mon, 11 Apr 2011 16:39:30 +0200
> Vincent Lefevre <vincent@vinc17.org> wrote:
> > and this is because the SIGWINCH seems to interrupt the "read"
> > (is it a bug?), so that
> > 
> >     while read -r $timeout -k -u 0 ch
> >     do
> >       line="$line$ch"
> >       [[ $ch = $'\012' ]] && break
> >       timeout=(-t 0.1)
> >     done
> > 
> > gives an empty string; hence the observed behavior.
> 
> Yes, we handle EINTR in most places and should do so here.  There are
> lots of nasty special cases in bin_read(); I think this is this one.
[...]

Thanks, I confirm that the problem has been fixed with the latest
zsh-beta upgrade under Debian.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)