resizing terminal window crashes bzr with EINTR

Which versions of bzr and Python, out of interest?

This is caused by a Python bug: <http://bugs.python.org/issue8354>.

There's a partial workaround in trunk. I'll backport that to 2.1.x now. Without the workaround the first signal causes no problems, but subsequent ones trigger the interrupted system call error.

Due to the nature of the Python bug, the workaround doesn't fix the case where multiple signals arrive before the interrupted syscall returns control to the Python interpreter.

Given that the fix for Python isn't yet Python's trunk (let alone a released version of Python) we may need to reconsider using SIGWINCH at all, or perhaps write a C extension to handle it rather than Python's flawed signal handling.

See also the discussion at <https://code.edge.launchpad.net/~spiv/bzr/i-hate-signals/+merge/23004>

It's bzr 2.2.0dev from about two weeks ago, and python 2.6.1.

From your description, it appears that my version of bzr has the workaround. This is a terminal that does live resize and resizing a window quickly causes a flood of SIGWINCH. Resizing the window slowly (i.e. no more than one SIGWINCH per syscall) helps.

I wasn't sure this is very important before, but now I start wondering if there is a way to be a better idiot and cause some data corruption with live resize ;-)

Daniel Fischer wrote:
[...]
> I wasn't sure this is very important before, but now I start wondering
> if there is a way to be a better idiot and cause some data corruption
> with live resize ;-)

Happily no. We handle EINTR sanely now: we retry the operation in the
relatively few cases where it is safe to do so, and the rest of the time
it just propagates the exception. Aborting with EINTR is ugly, but it
won't corrupt your data (bzr is pretty careful about doing atomic
operations).

Thanks for the details. I think unfortunately we do need a stronger
workaround than the current band-aid.

This was fixed a while back (in 2.1.2. and 2.2b3), by not using SIGWINCH at all.