Bug: Readline getting stuck on Linux and Solaris

[Leo Razoumov]

I recently compiled Python 2.0 for SUN Solaris 2.6 (SunOS 5.6)

Indeed, I had bad luck with readline-4.1 (it linked but some Python tests dumped
core). 

However it all went fine when I linked python against readline-4.0 (as found in
gdb-5.0 distro) and replaced -ltermcap with -ltermlib.

Everything works just fine now!

Just my two cents,
--Leo [slonika at yahoo.com]



>>>>> "QD" == Quinn Dunkan <quinn at dinar.ugcs.caltech.edu> writes:

    QD> 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?

    QD> Here are some more details tracebacks (|fmt'ed to shut up slrn):

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

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

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

    QD> Another Indigo2 with the same stats gives:
    QD> (dbx) where
    >> 0 _getpid(0x1, 0x7fcd30b0, 0x0, 0x0, 0x0, 0x1, 0x0, 0xc374f0c)
    QD> ["/xlv47/6.5.8m/work/irix/lib/libc/libc_n32_M4/proc/getpid.s":15, 0xfabb9f8]
    QD>    1 <Unknown>() [< unknown >, 0x5ffdd33c]

    QD> when it locks after a while 1 ^C, and

    >> 0 __ioctl(0x0, 0x54d5, 0x7fabcb40, 0x0, 0x0, 0x0, 0x0, 0x0)
    QD> ["/xlv47/6.5.8m/work/irix/lib/libc/libc_n32_M4/sys/ioctl.s":20, 0xfafebf8]
    QD>    1 _ioctl(0x0, 0x54d5, 0x7fabcb40, 0x0, 0x0, 0x0, 0x0, 0x0)
    QD> ["/xlv47/6.5.8m/work/irix/lib/libc/libc_n32_M4/sys/ioctlSCI.c":28, 0xfb0789c]
    QD>    2 ___new_tcgetattr(0x0, 0x54d5, 0x7fabcb40, 0x0, 0x0, 0x0, 0x0, 0x0)
    QD> ["/xlv47/6.5.8m/work/irix/lib/libc/libc_n32_M4/term/new_tcgetattr.c":26,
    QD> 0xfb0aa60]
    QD>    3 <Unknown>() [< unknown >, 0x5ffd22c8]

    QD> (varies, but always begins with the ioctls) after a ^C after the prompt first
    QD> appears.

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

    QD> Oh, and I used dbx because gdb isn't on all the machines, and it seems to give
    QD> more info anyway (maybe gdb doesn't agree with sgi cc compiled libs).  The
    QD> second indigo2 and the indy compiled python and readline with gcc, while the
    QD> first indigo2 uses sgi cc, so perhaps that accounts for the more complete,
    QD> consistent, and less confusing info from the first one. All of them lock up on
    QD> ^C, even under 'while 1: pass'.  They all work correctly if readline is not
    QD> imported, or if I manage to hit ^C before readline is imported.  Two of them
    QD> work fine when threads aren't compiled in, and I assume the third one would
    QD> too, but I haven't tested it.

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


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

    QD> ... just what we need!  Two compilers, two ABIs, 32 bit and 64 bit arches,
    QD> 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

    QD> Y'know, those random quote sigs can be eerily apropos.  "terminal" insanity
    QD> indeed.