Bug: Readline getting stuck on Linux and Solaris

[Michael Hudson]

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

> On 12 Dec 2000 23:53:56 +0000, Michael Hudson <mwh21 at cam.ac.uk> wrote:
> >quinn at ngwee.ugcs.caltech.edu (Quinn Dunkan) writes:
> >> (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 ()
> >
> >Can I see some more of this, please?
> 
> Here are some more details tracebacks (|fmt'ed to shut up slrn):

Ta.
 
> I get this trace when I do a ^C on an Indigo2 (IRIX64 6.5), even if I do
> the ^C after a 'while 1: pass'.  

That's interesting.  This would seem to support my theory that
readline is attempting to restore Python's SIGINT handler but failing
and reraising SIGINT, thus calling rl_signal_handler again.

The fact that you get this sort of thing if the while 1: pass case
sounds very much like a readline bug - you just shouldn't be ending up
in readline's signal handlers if you're not in a call to readline!
Though it might well be a bug somewhere else causing problems for
readline - but I doubt it's in Python.  Are there any other
multi-threaded apps that you know of that use readline?  Do they work?
If someone with an account on an IRIX box could whip up a very simple
threaded C program that calls readline, that'd perhaps eliminate a few
problem areas.

> Another Indigo2 with the same stats gives:
> (dbx) where
> >  0 _getpid(0x1, 0x7fcd30b0, 0x0, 0x0, 0x0, 0x1, 0x0, 0xc374f0c)
> ["/xlv47/6.5.8m/work/irix/lib/libc/libc_n32_M4/proc/getpid.s":15, 0xfabb9f8]
>    1 <Unknown>() [< unknown >, 0x5ffdd33c]
> 
> when it locks after a while 1 ^C, and
> 
> >  0 __ioctl(0x0, 0x54d5, 0x7fabcb40, 0x0, 0x0, 0x0, 0x0, 0x0)
> ["/xlv47/6.5.8m/work/irix/lib/libc/libc_n32_M4/sys/ioctl.s":20, 0xfafebf8]
>    1 _ioctl(0x0, 0x54d5, 0x7fabcb40, 0x0, 0x0, 0x0, 0x0, 0x0)
> ["/xlv47/6.5.8m/work/irix/lib/libc/libc_n32_M4/sys/ioctlSCI.c":28, 0xfb0789c]
>    2 ___new_tcgetattr(0x0, 0x54d5, 0x7fabcb40, 0x0, 0x0, 0x0, 0x0, 0x0)
> ["/xlv47/6.5.8m/work/irix/lib/libc/libc_n32_M4/term/new_tcgetattr.c":26,
> 0xfb0aa60]
>    3 <Unknown>() [< unknown >, 0x5ffd22c8]
> 
> (varies, but always begins with the ioctls) after a ^C after the
> prompt first appears.

Well, these could be more or less the same traces but with less error
info, couldn't they?

> Ok, on an Indy1 (plain IRIX 6.5), I get the same sort of thing.
> Which is weird, because I coulda sworn when I tried it before,
> 'while 1: pass' ^C worked right on the indy but not on the indigo.

Well, I'll take unexplained consistency if I can find it.

> Oh, and I used dbx because gdb isn't on all the machines, and it
> seems to give more info anyway (maybe gdb doesn't agree with sgi cc
> compiled libs).  The second indigo2 and the indy compiled python and
> readline with gcc, while the first indigo2 uses sgi cc, so perhaps
> that accounts for the more complete, consistent, and less confusing
> info from the first one.

Oh right, that seems like a good explanation.  Good, things aren't
being totally random...

> All of them lock up on ^C, even under 'while 1: pass'.  They all
> work correctly if readline is not imported, or if I manage to hit ^C
> before readline is imported.  Two of them work fine when threads
> aren't compiled in, and I assume the third one would too, but I
> haven't tested it.

Seems very likely.

Does Python also hang if you kill -INT it from another terminal?  What
about, say, kill -QUIT?  The readline docs say:

Readline contains an internal signal handler that is installed for a
number of signals (SIGINT, SIGQUIT, SIGTERM, SIGALRM, SIGTSTP,
SIGTTIN, and SIGTTOU).

so I'm wondering if all of those will hang Python...

> I also grepped through the preprocessed source of readline, and
> found sigactions() but no signals() (well, except in the included
> protos).  I also tried readline-2.2.1; no luck.

OK, so this might not be readline's fault.

> But that first traceback is nice, because it manages to implicate signals,
> readline, and libpthread all at once :)

Yes.  On an operating system I have no experience with.  We'll get
there yet :-).

> ... just what we need!  Two compilers, two ABIs, 32 bit and 64 bit arches,
> multiple library versions, and inconsistent errors!  Irix is such fun.

Sounds it.  Is there a readline mailing list anywhere?  I wonder if
moaning to them would get the response "oh, that!  it's an Irix
bug...".  Although pthreads may be more likely.

> >-- 
> >  In general, I'd recommend injecting LSD directly into your temples,
> >  Syd-Barret-style, before mucking with Motif's resource framework.
> >  The former has far lower odds of leading directly to terminal
> >  insanity.                                            -- Dan Martinez
> 
> Y'know, those random quote sigs can be eerily apropos.  "terminal" insanity
> indeed.

Indeed.

Cheers,
M.

-- 
  In case you're not a computer person, I should probably point out
  that "Real Soon Now" is a technical term meaning "sometime before
  the heat-death of the universe, maybe". 
                                     -- Scott Fahlman <sef at cs.cmu.edu>