Bug: Readline getting stuck on Linux and Solaris

Wed Dec 13 17:07:09 EST 2000

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):

(dbx) where
>  0 __ioctl(0x0, 0x54d7, 0x5fff9d68, 0x0, 0xc, 0xc, 0x7fe35d90, 0x0)
["/xlv51/6.5.5f/work/irix/lib/libc/libc_n32_M3/sys/ioctl.s":20, 0xfaf7dbc] 1
_ioctl(0x0, 0x54d7, 0x5fff9d68, 0x0, 0xc, 0xc, 0x7fe35d90, 0x0)
["/xlv51/6.5.5f/work/irix/lib/libc/libc_n32_M3/sys/ioctlSCI.c":28, 0xfb00720]
   2 ___new_tcsetattr(0x0, 0x54d7, 0x5fff9d68, 0x0, 0xc3ac600, 0xc,
0x7fe35d90, 0x0)
["/xlv51/6.5.5f/work/irix/lib/libc/libc_n32_M3/term/new_tcsetattr.c":61,
0xfb03878]
   3 tcsetattr(__fd = 0, __act = 21519, __t = 0x5fff9d68)
["/usr/include/sys/termios.h":136, 0x5ffc62f4]
   4 set_tty_settings(tty = 0, tiop = 0x5fff9d68)
["/usr/local/src/readline-4.0/rltty.c":428, 0x5ffc6544]
   5 rl_deprep_terminal() ["/usr/local/src/readline-4.0/rltty.c":581,
0x5ffc6954]
   6 rl_cleanup_after_signal() ["/usr/local/src/readline-4.0/signals.c":361,
0x5ffd655c]
   7 rl_signal_handler(sig = 2) ["/usr/local/src/readline-4.0/signals.c":157,
0x5ffd5f84]
   8 sig_fixup_mask(0x0, 0x54d7, 0x5fff9d68, 0x0, 0xc, 0xc, 0x7fe35d90, 0x0)
["/xlv51/6.5.5f/work/eoe/lib/libpthread/libpthread_n32_M3/sig.c":446,
0xc38ebb0]
   9 _sigtramp(0x0, 0x54d7, 0x0, 0x0, 0xc, 0xc, 0x7fe35d90, 0x0)
["/xlv51/6.5.5f/work/irix/lib/libc/libc_n32_M3/signal/sigtramp.s":71,
0xfac93c0]
   10 _ksigaction(0x2, 0x7fe362f8, 0x5fff9ea0, 0x0, 0x11e1000, 0x7fe362f8,
0x7fe363c0, 0xc3a4cb8)
["/xlv51/6.5.5f/work/irix/lib/libc/libc_n32_M3/signal/ksigaction.s":23,
0xfac92ec]
   11 _SGIPT_libc_sigaction(0x2, 0x7fe362f8, 0x5fff9ea0, 0x5ffd5f20,
0x11e1000, 0x7fe362f8, 0x7fe363c0, 0xc3a4cb8)
["/xlv51/6.5.5f/work/eoe/lib/libpthread/libpthread_n32_M3/sig.c":419,
0xc38eab8]
   12 ptctl(0x2, 0x7fe362f8, 0x5fff9ea0, 0x0, 0x11e1000, 0x7fe362f8,
0x7fe363c0, 0xc3a4cb8)
["/xlv51/6.5.5f/work/eoe/lib/libpthread/libpthread_n32_M3/libcthread.c":149,
0xc387cd4]
   13 _sigaction(0x2, 0x7fe362f8, 0x5fff9ea0, 0x0, 0x11e1000, 0x7fe362f8,
0x7fe363c0, 0xc3a4cb8)
["/xlv51/6.5.5f/work/irix/lib/libc/libc_n32_M3/signal/sigaction.c":26,
0xfac98b4]
   14 rl_set_sighandler(sig = 2, handler = 0x5ffd5f20, ohandler = 0x5fff9ea0)
["/usr/local/src/readline-4.0/signals.c":242, 0x5ffd60f4]
   15 rl_maybe_set_sighandler(sig = 2, handler = 0x5ffd5f20, ohandler =
0x5fff9ea0) ["/usr/local/src/readline-4.0/signals.c":259, 0x5ffd6158]
   16 rl_set_signals() ["/usr/local/src/readline-4.0/signals.c":272,
0x5ffd61f0]
   17 rl_reset_after_signal() ["/usr/local/src/readline-4.0/signals.c":371,
0x5ffd65c4]
   18 rl_signal_handler(sig = 2) ["/usr/local/src/readline-4.0/signals.c":179,
0x5ffd5ff8]
   19 sig_fixup_mask(0x2, 0x7fe362f8, 0x5fff9ea0, 0x0, 0x11e1000, 0x7fe362f8,
0x7fe363c0, 0xc3a4cb8)
["/xlv51/6.5.5f/work/eoe/lib/libpthread/libpthread_n32_M3/sig.c":446,
0xc38ebb0]
   20 _sigtramp(0x0, 0x7fe362f8, 0x0, 0x0, 0x11e1000, 0x7fe362f8, 0x7fe363c0,
0xc3a4cb8)
["/xlv51/6.5.5f/work/irix/lib/libc/libc_n32_M3/signal/sigtramp.s":71,
0xfac93c0]
   21 _ksigaction(0x2, 0x7fe36918, 0x5fff9ea0, 0x0, 0x11e1000, 0x7fe36918,
0x7fe369e0, 0xc3a4cb8)
["/xlv51/6.5.5f/work/irix/lib/libc/libc_n32_M3/signal/ksigaction.s":23,
0xfac92ec]
   22 _SGIPT_libc_sigaction(0x2, 0x7fe36918, 0x5fff9ea0, 0x5ffd5f20,
0x11e1000, 0x7fe36918, 0x7fe369e0, 0xc3a4cb8)
["/xlv51/6.5.5f/work/eoe/lib/libpthread/libpthread_n32_M3/sig.c":419,
0xc38eab8]

[ ... 11--21 loop forever ... ]

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'.  

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.

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.

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. 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.

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.

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

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

>-- 
>  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.