strange behaviour of bash-4.0.17 when used in urxvt

[Marc Lehmann]

On Fri, Apr 10, 2009 at 02:58:16PM -0400, Aron Griffis <agriffis at n01se.net> wrote:
> I think the interesting part starts at line 9207, where bash (pid
> 11715) writes some of the prompt.  It's then interrupted by
> SIGWINCH.  On line 9218 it tries again, and on 9241 rxvt finishes
> reading from bash.

Yes, it's clearly a race inside bash - it writes the prompt another time
after it receives a SIGWINCH, while it was writing the first prompt.

11715 1239388944.954054 write(2, "\33[0m\33[32m--- \33[0m\33[01m\33[32m0 \33[0m"..., 135 <unfinished ...>
11715 1239388944.954406 <... write resumed> ) = 135
11715 1239388944.954421 --- SIGWINCH (Window changed) @ 0 (0) ---
11715 1239388944.954437 ioctl(0, TIOCGWINSZ, {ws_row=13, ws_col=80, ws_xpixel=400, ws_ypixel=156}) = 0
11715 1239388944.954538 write(2, "\33[0m\33[32m--- \33[0m\33[01m\33[32m0 \33[0m"..., 154) = 154
11715 1239388944.954586 sigreturn()     = ? (mask now [])

Inside the signal handler, even...

> Not sure quite how to translate this into something actionable,
> though. :-)

This is probably just an artifact of bash bad prompt handling in general.
Maybe it's a race and bash should block sigwinch while it handles the
prompt.

Nothing urxvt can do about in this case, but this issue is different than
the one reported before (but likely is the same bug inside bash, just
different kernel behaviour or race).

Thanks for the strace!

-- 
                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_              http://www.deliantra.net
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      pcg at goof.com
      -=====/_/_//_/\_,_/ /_/\_\