zsh-4.3.1[45] problem on FreeBSD

zsh-4.3.1[45] problem on FreeBSD

[Herbert J. Skuhra]

Hi,

after upgrading zsh from version 4.3.12 to 4.3.14 (and later 4.3.15) I
have a strange problem on FreeBSD 9.0-PRELEASE (i386).

When I launch xterm/sakura/urxvt instead of the shell prompt I only see
the cursor.

96450 herbert       1  89    0 11452K  2888K RUN      0:49 59.96% zsh
96448 herbert       1  52    0 14372K  5944K select   0:35 40.97% xterm

Ktrace shows an endless loop of:

 96228 xterm    RET   read 4096/0x1000
 96228 xterm    CALL  select(0x5,0x809f900,0x809f880,0,0x809f878)
 96228 xterm    RET   select 1
 96228 xterm    CALL  sched_yield
 96228 xterm    RET   sched_yield 0
 96228 xterm    CALL  read(0x3,0x288ac018,0x1000)
 96228 xterm    RET   read -1 errno 35 Resource temporarily unavailable
 96228 xterm    CALL  read(0x3,0x288ac018,0x1000)
 96228 xterm    RET   read -1 errno 35 Resource temporarily unavailable
 96228 xterm    CALL  read(0x3,0x288ac018,0x1000)
 96228 xterm    RET   read -1 errno 35 Resource temporarily unavailable
 96228 xterm    CALL  poll(0x2886c648,0x1,0)
 96228 xterm    RET   poll 0
 96228 xterm    CALL  select(0x5,0x809f900,0x809f880,0,0)
 96228 xterm    RET   select 1
 96228 xterm    CALL  read(0x3,0x288ac018,0x1000)
 96228 xterm    RET   read -1 errno 35 Resource temporarily unavailable
 96228 xterm    CALL  read(0x3,0x288ac018,0x1000)
 96228 xterm    RET   read -1 errno 35 Resource temporarily unavailable
 96228 xterm    CALL  poll(0x2886c648,0x1,0)
 96228 xterm    RET   poll 0
 96228 xterm    CALL  read(0x4,0x28aa101c,0x1000)
 96228 xterm    GIO   fd 4 read 3716 bytes
       0x0000 5b41 1b5b 411b 5b41 1b5b 411b 5b41 1b5b 411b 5b41 1b5b 411b  |[A.[A.[A.[A.[A.[A.[A.[A.|
       0x0018 5b41 1b5b 411b 5b41 1b5b 411b 5b41 1b5b 411b 5b41 1b5b 411b  |[A.[A.[A.[A.[A.[A.[A.[A.|
       0x0030 5b41 1b5b 411b 5b41 1b5b 411b 5b41 1b5b 411b 5b41 1b5b 411b  |[A.[A.[A.[A.[A.[A.[A.[A.|
       0x0048 5b41 1b5b 411b 5b41 1b5b 411b 5b41 1b5b 411b 5b41 1b5b 411b  |[A.[A.[A.[A.[A.[A.[A.[A.|
       0x0060 5b41 1b5b 411b 5b41 1b5b 411b 5b41 1b5b 411b 5b41 1b5b 411b  |[A.[A.[A.[A.[A.[A.[A.[A.|
       [snip]

-- 
Herbert

Re: zsh-4.3.1[45] problem on FreeBSD

[Herbert J. Skuhra]

On Mon, 26 Dec 2011 21:01:58 +0100
"Herbert J. Skuhra" <hskuhra@fastmail.fm> wrote:

> Hi,
> 
> after upgrading zsh from version 4.3.12 to 4.3.14 (and later 4.3.15) I
> have a strange problem on FreeBSD 9.0-PRELEASE (i386).
> 
> When I launch xterm/sakura/urxvt instead of the shell prompt I only see
> the cursor.

Hmm, after reverting the commit "188abdd708a9a03ff44b5361d028a9953701250e"
the problem is gone.

-- 
Herbert

Re: zsh-4.3.1[45] problem on FreeBSD

[Bart Schaefer]

On Dec 26,  9:01pm, Herbert J. Skuhra wrote:
}
} after upgrading zsh from version 4.3.12 to 4.3.14 (and later 4.3.15) I
} have a strange problem on FreeBSD 9.0-PRELEASE (i386).
} 
} When I launch xterm/sakura/urxvt instead of the shell prompt I only see
} the cursor.

Hrm.  This must have something to do with TIOCGWINSZ not being defined
on that platform and something causing re-entry into adjustwinsize(),
but I don't have a FreeBSD system to test on and I can't tell whether
it's a recursive call or simply that we've created an infinite series
of SIGWINCH somehow.

Staring at the code in adjustwinsize() makes me suspect the SIGWINCH,
as improbable as that seems.

Can you reproduce this with "zsh -f"?  If not, what are the values of
your PS1 and RPS1 parameters?

Re: zsh-4.3.1[45] problem on FreeBSD

[Herbert J. Skuhra]

On Mon, 26 Dec 2011 18:31:40 -0800
Bart Schaefer <schaefer@brasslantern.com> wrote:

> On Dec 26,  9:01pm, Herbert J. Skuhra wrote:
> }
> } after upgrading zsh from version 4.3.12 to 4.3.14 (and later 4.3.15) I
> } have a strange problem on FreeBSD 9.0-PRELEASE (i386).
> } 
> } When I launch xterm/sakura/urxvt instead of the shell prompt I only see
> } the cursor.
> 
> Hrm.  This must have something to do with TIOCGWINSZ not being defined
> on that platform and something causing re-entry into adjustwinsize(),
> but I don't have a FreeBSD system to test on and I can't tell whether
> it's a recursive call or simply that we've created an infinite series
> of SIGWINCH somehow.

% ./configure
[...]
checking for conflicts in sys/time.h and sys/select.h... no
checking TIOCGWINSZ in termios.h... yes
checking for streams headers including struct winsize... no
checking for printf in -lc... yes
[...]
 
> Staring at the code in adjustwinsize() makes me suspect the SIGWINCH,
> as improbable as that seems.
> 
> Can you reproduce this with "zsh -f"?

Yes.
  
> If not, what are the values of your PS1 and RPS1 parameters?

(PS1 is %m%# and RPS1 is unset)

Thanks.

-- 
Herbert

Re: zsh-4.3.1[45] problem on FreeBSD

[Bart Schaefer]

On Tue, Dec 27, 2011 at 12:38 PM, Herbert J. Skuhra <hskuhra@fastmail.fm> wrote:
> On Mon, 26 Dec 2011 18:31:40 -0800
> Bart Schaefer <schaefer@brasslantern.com> wrote:
>
>> Hrm.  This must have something to do with TIOCGWINSZ not being defined
>> on that platform and something causing re-entry into adjustwinsize(),
>> but I don't have a FreeBSD system to test on and I can't tell whether
>> it's a recursive call or simply that we've created an infinite series
>> of SIGWINCH somehow.
>
> % ./configure
> [...]
> checking for conflicts in sys/time.h and sys/select.h... no
> checking TIOCGWINSZ in termios.h... yes

Hrm again.  Nothing interesting happens in zle_resetprompt() as far as
I can tell:

zle_resetprompt(void)
{
    reexpandprompt();
    if (zleactive)
        redisplay(NULL);
}

And:

redisplay(UNUSED(char **args))
{
    moveto(0, 0);
    zputc(&zr_cr);              /* extra care */
    tc_upcurs(lprompth - 1);
    resetneeded = 1;
    clearflag = 0;
    return 0;
}

So unless the curses library is doing something wacko, I can't find
any reason why it would be a problem to reset the prompt before /
independently of calling zrefresh().

However, adjustwinsize() it is literally the only place
zle_resetprompt() is called; usually resetting the prompt is done via
a widget if at all.

Out of curiosity, what happens if you put a "sleep 5" somewhere in
your init files?  I'm wondering if there's some kind of race between
the terminal getting opened and the first attempt to output something.

Re: zsh-4.3.1[45] problem on FreeBSD

[Herbert J. Skuhra]

On Tue, 27 Dec 2011 16:53:15 -0800
Bart Schaefer <schaefer@brasslantern.com> wrote:
 
> Out of curiosity, what happens if you put a "sleep 5" somewhere in
> your init files?  I'm wondering if there's some kind of race between
> the terminal getting opened and the first attempt to output something.

Adding a "sleep x" (x >= 0) to ~/.zshrc does indeed help.

Thanks.

-- 
Herbert

Re: zsh-4.3.1[45] problem on FreeBSD

[Bart Schaefer]

On Jan 1,  3:25pm, Herbert J. Skuhra wrote:
} Subject: Re: zsh-4.3.1[45] problem on FreeBSD
}
} On Tue, 27 Dec 2011 16:53:15 -0800
} Bart Schaefer <schaefer@brasslantern.com> wrote:
}  
} > Out of curiosity, what happens if you put a "sleep 5" somewhere in
} > your init files?  I'm wondering if there's some kind of race between
} > the terminal getting opened and the first attempt to output something.
} 
} Adding a "sleep x" (x >= 0) to ~/.zshrc does indeed help.

Ahh, with that bit of data everything else makes a lot more sense.

Unfortunately I'm not entirely sure what to do about it.  In order for
the the ZLE_CMD_RESET_PROMPT change to have made a difference to the
behavior, the SIGWINCH must be arriving after zleread() is called for
the first time, because that's where zleactive gets set to 1, but it
isn't possible to tell exactly where in zleread() that happens.

Try the patch below (with the "sleep" removed from .zshrc) and let us
know if it resolves the problem?

If it does, I wonder if we should just queue_signals()/unqueue_signals()
around the entire body of zrefresh(), always?  Or is this the only place
that's important?  (And is it important to protect initmodifier() too?
[one line below the context shown in the first hunk of this patch])

Index: zle_main.c
===================================================================
RCS file: /extra/cvsroot/zsh/zsh-4.0/Src/Zle/zle_main.c,v
retrieving revision 1.39
diff -c -r1.39 zle_main.c
--- zle_main.c	20 Dec 2011 17:13:38 -0000	1.39
+++ zle_main.c	1 Jan 2012 20:05:30 -0000
@@ -1200,6 +1200,9 @@
 	putc('\r', shout);
     if (tmout)
 	alarm(tmout);
+
+    queue_signals();
+
     zleactive = 1;
     resetneeded = 1;
     errflag = retflag = 0;
@@ -1208,6 +1211,7 @@
     prefixflag = 0;
 
     zrefresh();
+    unqueue_signals();
 
     zlecallhook("zle-line-init", NULL);
 

Re: zsh-4.3.1[45] problem on FreeBSD

[Herbert J. Skuhra]

On Sun, Jan 1, 2012, at 12:08, Bart Schaefer wrote:

> Try the patch below (with the "sleep" removed from .zshrc) and let us
> know if it resolves the problem?

It does. Thank you.

-- 
Herbert

Re: zsh-4.3.1[45] problem on FreeBSD

[Bart Schaefer]

On Jan 1, 12:08pm, Bart Schaefer wrote:
}
} I wonder if we should just queue_signals()/unqueue_signals() around
} the entire body of zrefresh(), always?  Or is this the only place
} that's important?

As Herbert has now confirmed that the race can be resolved --

Although it probably wouldn't hurt anything to queue signals around
the bulk of zrefresh(), this part of zleread() is the only point at
which zleactive can be true before at least one call to zrefresh()
has completed; which, I think, means this is the only place where a
SIGWINCH could cause confusion.

I'd still like to know more about exactly what goes on under FreeBSD
in the case where it hangs, but I think the conservative approach is
to restrict the signal queuing to this one section.  I'll add a few
lines of comment and commit the patch.

Adding a further queue/unqueue inside zrefresh() later won't conflict,
should we find another such race condition.

Re: zsh-4.3.1[45] problem on FreeBSD

[Bart Schaefer]

On Jan 2, 12:38pm, Herbert J. Skuhra wrote:
} Subject: Re: zsh-4.3.1[45] problem on FreeBSD
}
} On Sun, Jan 1, 2012, at 12:08, Bart Schaefer wrote:
} 
} > Try the patch below (with the "sleep" removed from .zshrc) and let us
} > know if it resolves the problem?
} 
} It does. Thank you.

Thanks for your help with diagnosis.

One other question, more of curiosity than anything else:  Does your
desktop or window manager open terminal windows in an "animated" way,
e.g., zoom them from a small size to fully open to give the illusion
of them popping up from an icon or task bar, or some such thing?

Just wondering if there's a reason zsh might be receiving a stream
of window size change notifications, beyond the simple race condition.

Re: zsh-4.3.1[45] problem on FreeBSD

[Herbert J. Skuhra]

On Mon, Jan 2, 2012, at 11:36, Bart Schaefer wrote:
> On Jan 2, 12:38pm, Herbert J. Skuhra wrote:
> } Subject: Re: zsh-4.3.1[45] problem on FreeBSD
> }
> } On Sun, Jan 1, 2012, at 12:08, Bart Schaefer wrote:
> } 
> } > Try the patch below (with the "sleep" removed from .zshrc) and let us
> } > know if it resolves the problem?
> } 
> } It does. Thank you.
> 
> Thanks for your help with diagnosis.
> 
> One other question, more of curiosity than anything else:  Does your
> desktop or window manager open terminal windows in an "animated" way,
> e.g., zoom them from a small size to fully open to give the illusion
> of them popping up from an icon or task bar, or some such thing?

Hmm, I am using musca and xmonad.

In musca I split the screen vertically at 50% and then I split the right pane horizontally at 50%.
Then I launch emacs, sakura/xterm/urxvt, etc.

In xmonad the screen is split when I launch the terminal; first vertically and then horizontally.

Problem happened with both window managers, even in unsplit/fullscreen mode, but only on FreeBSD.
No problem on Arch GNU/Linux running on a 10" netbook (unsplit screen).

I can try a different window manager (openbox?) on FreeBSD with unpatched zsh.

-- 
Herbert

Re: zsh-4.3.1[45] problem on FreeBSD

[Baptiste Daroussin]

2012/1/3 Herbert J. Skuhra <hskuhra@fastmail.fm>:
> On Mon, Jan 2, 2012, at 11:36, Bart Schaefer wrote:
>> On Jan 2, 12:38pm, Herbert J. Skuhra wrote:
>> } Subject: Re: zsh-4.3.1[45] problem on FreeBSD
>> }
>> } On Sun, Jan 1, 2012, at 12:08, Bart Schaefer wrote:
>> }
>> } > Try the patch below (with the "sleep" removed from .zshrc) and let us
>> } > know if it resolves the problem?
>> }
>> } It does. Thank you.
>>
>> Thanks for your help with diagnosis.
>>
>> One other question, more of curiosity than anything else:  Does your
>> desktop or window manager open terminal windows in an "animated" way,
>> e.g., zoom them from a small size to fully open to give the illusion
>> of them popping up from an icon or task bar, or some such thing?
>
> Hmm, I am using musca and xmonad.
>
> In musca I split the screen vertically at 50% and then I split the right pane horizontally at 50%.
> Then I launch emacs, sakura/xterm/urxvt, etc.
>
> In xmonad the screen is split when I launch the terminal; first vertically and then horizontally.
>
> Problem happened with both window managers, even in unsplit/fullscreen mode, but only on FreeBSD.
> No problem on Arch GNU/Linux running on a 10" netbook (unsplit screen).
>
> I can try a different window manager (openbox?) on FreeBSD with unpatched zsh.
>
> --
> Herbert

I have tried with i3, and pekwm on FreeBSD, I don't have the problem
with pekwm, but I got it with i3 from time to time, I'll test the
patch and add it to the FreeBSD port as soon as I can.

regards,
Bapt