Bug: Readline getting stuck on Linux and Solaris

[Michael Hudson]

quinn at ngwee.ugcs.caltech.edu (Quinn Dunkan) writes:

> On 07 Dec 2000 09:57:23 +0000, Michael Hudson <mwh21 at cam.ac.uk> wrote:
> >quinn at lira.ugcs.caltech.edu (Quinn Dunkan) writes:
> >
> >> Strange.. readline has *never* worked right for me, on IRIX or
> >> Linux, on any version of python (1.4, 1.5.2, 2.0), and any version
> >> of readline (3.0, 4.0, 4.1), if python is compiled with threads.
> >> IRIX (6.4, 6.5, 6.5.2) hangs, Linux (2.0.36, 2.2.12, 2.2.17) exits.
> 
> Well, blow me down and pick me up, I just tried python 2.0 on linux (it was
> 2.0b1 before) and the problem is solved, even with threads.

Ah yes; it was a pretty late fix.

> >Well, I have readline 2.2.1, which may make a difference.  Can you
> >supply a stacktrace?
> >
> >> I just tried your 'while 1: pass' thing, and the behaviour is the same there
> >> too.
> >
> >That really is odd, because readline doesn't have control then and
> >should be out of the picture.  Does control-C work as expected here if
> >readline isn't enabled, or if you hit it before the first prompt
> >appears (this may be tricky).
> 
> It's not tricky on an Indy :) In any case, on the irix machine, I've
> been using 2.0-for-real and it still locks.  It apparently works ok
> if I hit control C quickly: I get 'import site' failed, presumably
> because it died of a KeyboardInterrupt.  However, even a 'while 1:
> pass' ^C locks.  I got a backtrace by suspending the locked python,
> and killng it with a SIGILL to get a core.

Well, this sounds like a readline bug to me (or maybe an IRIX oddity
that readline fails to work it's way around).

Do other proggies that use readline work properly?

> (gdb) bt
> #0  0xfa3ab88 in __ioctl () at lio.c:201
> #1  0xfa434f0 in ioctl () at nftw.c:184
> #2  0x5ffd2a74 in rl_restart_output ()
> #3  0x5ffdd0f4 in _rl_clean_up_for_exit ()
> #4  0x5ffdd860 in rl_cleanup_after_signal ()
> #5  0x5ffdd304 in _rl_erase_entire_line ()

Was this backtrace from the "while 1: pass" hang?  If it was, it's
mightily strange that we seem to be in readline code.

> Once again, Irix has no problems if I compile --without-threads
> (which "fixed" the linux problem too, so I assumed they were the
> same bug).  This is Irix 6.5, with gcc 2.8.1 and realine 4.  On
> Monday I'll try with readline 2 and see if it's still there.

I suspect this will make no difference - but it's probably worth
checking.

> ^C works properly in all instances if readline is disabled (via 'mv
> readline.so spam', if there's a more graceful way I don't know it).

No, that's probably the best way.

All I can think of is that there's some fuck-up in restoring signals
(maybe a sysV vs. BSD misunderstanding?).  On catching a signal,
readline does some clean-up, restores the application's original
signal handler and re-sends the signal.  So if for some reason
readline is unable to restore Python's handler, one could see how it
might just spin.  But this is very rapidly getting beyond my
experience - I don't think I've ever even seen an IRIX box...

Ooh, I wonder if readline uses signal(2) rather than sigaction to
reset the the signal - that would probably go wrong.  If that is the
problem, I can't really see a way around it, other than to hack
readline into using sigaction...  do the IRIX manpages say anything
scary about signal/sigaction interaction?

disconnected-ly y'rs
M.

-- 
48. The best book on programming for the layman is "Alice in
    Wonderland";  but  that's because it's  the best book on 
    anything for the layman.
  -- Alan Perlis, http://www.cs.yale.edu/homes/perlis-alan/quotes.html