Hotwire hangs when typing German Umlaute in Input Mode

[GoogleCodeExporter]

What steps will reproduce the problem?
1. type 
  | sh echo "Sample question? [y/n]"; read ans; echo "You answered ${ans}"
2. activate Input Mode
3. type Ü<enter>

What is the expected output? What do you see instead?
Hotwire window is completely freezed.
After pressing CTL+C in console, I got following stack trace: 

Traceback (most recent call last):
  File "/usr/lib/python2.5/site-packages/hotwire/async.py", line 106, in
__do_idle
    return handler(self, *self.__handler_args)
  File "/usr/lib/python2.5/site-packages/hotwire/builtins/sys_builtin.py",
line 80, in __on_input
    stream.write(unicode(val))
  File "/usr/lib/python2.5/site-packages/hotwire/builtins/sys_builtin.py",
line 57, in write
    count = os.write(self.fd, buf[offset:])
KeyboardInterrupt

Afterwards the text correctly appears inside Hotwire. 

I'm using Hotwire 0.721 on Ubuntu 7.04 with python 2.5.1.

Original issue reported on code.google.com by dienhardt@gmail.com on 14 Apr 2008 at 7:10

[GoogleCodeExporter]

This is an interesting bug.  So what happens is we spin using 100% CPU, with two
active threads.  The main loop thread is stuck in write():

Thread 1 (Thread 0x7fab666ab6f0 (LWP 8538)):
#0  0x00000034e8c0db0b in write () from /lib64/libpthread.so.0
#1  0x00000034ff0ec283 in posix_write (self=<value optimized out>, 
    args=<value optimized out>) at Modules/posixmodule.c:6125
#2  0x00000034ff0bde7d in PyEval_EvalFrameEx (f=<value optimized out>, 
    throwflag=<value optimized out>) at Python/ceval.c:3564
#3  0x00000034ff0beee6 in PyEval_EvalFrameEx (f=<value optimized out>, 
    throwflag=<value optimized out>) at Python/ceval.c:3650

There's a secondary thread waiting for a mutex:

Thread 2 (Thread 0x40ef4950 (LWP 8544)):
#0  0x00000034e8c0cf31 in sem_wait () from /lib64/libpthread.so.0
#1  0x00000034ff0e4aa8 in PyThread_acquire_lock (lock=<value optimized out>, 
    waitflag=<value optimized out>) at Python/thread_pthread.h:349
#2  0x00000034ff0e8a52 in lock_PyThread_acquire_lock (self=<value optimized 
out>, 
    args=<value optimized out>) at Modules/threadmodule.c:46
#3  0x00000034ff0bde7d in PyEval_EvalFrameEx (f=<value optimized out>, 
    throwflag=<value optimized out>) at Python/ceval.c:3564

I'm fairly sure the first thread's write is ultimately from
sys_builtin.py:__on_input.  The second thread is a mystery at the moment.

One theory I have is that the shell subprocess is reading the first byte from 
the
response, and then exiting.  At that point though, because we're using UTF-8, we
still have another byte to write from the 'Ü'.  Perhaps Python's standard IO 
isn't
correctly handling this case?

Original comment by cgwalt...@gmail.com on 24 Apr 2008 at 2:35

• Changed state: Accepted

[GoogleCodeExporter]

Actually no, according to strace we do write both bytes:

write(13, "\303\234\n", 3)              = 3

Then we get SIGCHLD, as expected:

--- SIGCHLD (Child exited) @ 0 (0) ---

But after that we spin in a loop:

write(13, "", 0)                        = 0
write(13, "", 0)                        = 0
write(13, "", 0)                        = 0
write(13, "", 0)                        = 0

Hmmm?  What is trying to write 0 bytes?

Noting it looks like the child process gets both bytes fine:

read(0, "\303\234\n", 128) = 3
write(1, "You answered \303\234\n", 16) = 16

Will investigate more.

Original comment by cgwalt...@gmail.com on 24 Apr 2008 at 2:58

[GoogleCodeExporter]

Got it, my bug!

Committed r1211
    M   hotwire/builtins/sys_builtin.py
r1211 = 32130e3d601b7aa32e8b50d9558f5cd86fbe6327 (git-svn)

Original comment by cgwalt...@gmail.com on 24 Apr 2008 at 4:25

• Changed state: Fixed