bug-readline
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug-readline] Problem with CTRL-z and readline()


From: Dave Anderson
Subject: [Bug-readline] Problem with CTRL-z and readline()
Date: Fri, 27 Feb 2015 12:10:15 -0500 (EST)

This issue was first reported with respect to the crash utility,
which is an interactive program that uses the readline library.  

The problem occurs only if the crash utility is run from within 
an executable bash script, i.e., like so:

  $ cat doit
  crash
  $

If crash is invoked as above, the crash utility does its initialization
and eventually calls readline().  Then, if CTRL-z is entered, the parent 
bash shell itself is blocked, but the crash utility spins at 100% cpu usage.
Debugging it shows that the crash utility is stuck spinning in the readline
libary's _set_tty_settings() function, where the tcsetattr() call repeatedly
fails with an EINTR, where _rl_caught_signal contains SIGTTOU.  

But taking the crash utility out of the picture, I can reproduce it with
readline-6.3.tar.gz, where I simply build it with "configure; make", then 
go into the examples subdirectory, and enter "make".  If I then put the
simple "rl" command in script file, and do the same thing, this happens:

  $ cat doit
  ./rl
  $ ./doit
  readline$ ^Z
  [1]+  Stopped                 ./doit
  $
  $ top
  top - 12:02:33 up 23:12,  5 users,  load average: 0.37, 0.09, 0.04
  Tasks: 159 total,   2 running, 154 sleeping,   3 stopped,   0 zombie
  Cpu(s):  3.4%us, 21.6%sy,  0.0%ni, 75.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
  Mem:   3917056k total,  3709052k used,   208004k free,    88732k buffers
  Swap:  4063228k total,        0k used,  4063228k free,  3049316k cached
  
    PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND          
                                                        
  12336 root      20   0  100m 1016  788 R 100.0  0.0   1:12.13 rl
      1 root      20   0 19356 1532 1216 S  0.0  0.0   0:02.89 init
      2 root      20   0     0    0    0 S  0.0  0.0   0:00.02 kthreadd
      3 root      RT   0     0    0    0 S  0.0  0.0   0:00.19 migration/0
  ...

   
If I attach gdb to the rl process above, it shows the same ultimate trace as
the spinning crash utility does:

  # gdb -p 12336
  GNU gdb (GDB) Red Hat Enterprise Linux (7.2-75.el6)
  Copyright (C) 2010 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
  This is free software: you are free to change and redistribute it.
  There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
  and "show warranty" for details.
  This GDB was configured as "x86_64-redhat-linux-gnu".
  For bug reporting instructions, please see:
  <http://www.gnu.org/software/gdb/bugs/>.
  Attaching to process 12336
  Reading symbols from /root/readline-6.3/examples/rl...done.
  Reading symbols from /lib64/libtinfo.so.5...Reading symbols from 
/usr/lib/debug/lib64/libtinfo.so.5.7.debug...done.
  done.
  Loaded symbols for /lib64/libtinfo.so.5
  Reading symbols from /lib64/libc.so.6...Reading symbols from 
/usr/lib/debug/lib64/libc-2.12.so.debug...done.
  done.
  Loaded symbols for /lib64/libc.so.6
  Reading symbols from /lib64/ld-linux-x86-64.so.2...Reading symbols from 
/usr/lib/debug/lib64/ld-2.12.so.debug...done.
  done.
  Loaded symbols for /lib64/ld-linux-x86-64.so.2
  0x00000033f52dff48 in tcsetattr (fd=0, optional_actions=<value optimized 
out>, termios_p=0x62cb60)
      at ../sysdeps/unix/sysv/linux/tcsetattr.c:84
  84      retval = INLINE_SYSCALL (ioctl, 3, fd, cmd, &k_termios);
  (gdb) bt
  #0  0x00000033f52dff48 in tcsetattr (fd=0, optional_actions=<value optimized 
out>, termios_p=0x62cb60)
      at ../sysdeps/unix/sysv/linux/tcsetattr.c:84
  #1  0x0000000000406f8d in _set_tty_settings (tty=0, tiop=0x62cb60) at 
rltty.c:476
  #2  0x0000000000406fe3 in set_tty_settings (tty=<value optimized out>, 
tiop=<value optimized out>) at rltty.c:490
  #3  0x00000000004072d0 in rl_deprep_terminal () at rltty.c:688
  #4  0x0000000000413352 in rl_cleanup_after_signal () at signals.c:536
  #5  0x0000000000413731 in _rl_handle_signal (sig=20) at signals.c:232
  #6  0x00000000004137e5 in _rl_signal_handler (sig=<value optimized out>) at 
signals.c:155
  #7  0x0000000000415575 in rl_getc (stream=0x33f558e6c0) at input.c:480
  #8  0x0000000000415a60 in rl_read_key () at input.c:462
  #9  0x000000000040340d in readline_internal_char () at readline.c:564
  #10 0x00000000004037d3 in readline_internal_charloop (prompt=<value optimized 
out>) at readline.c:629
  #11 readline_internal (prompt=<value optimized out>) at readline.c:643
  #12 readline (prompt=<value optimized out>) at readline.c:369
  #13 0x00000000004025b6 in main (argc=1, argv=0x7fff0af285d8) at rl.c:149
  (gdb) 
  (gdb) c
  Continuing.
  
  Program received signal SIGTTOU, Stopped (tty output).
  0x00000033f52dff48 in tcsetattr (fd=0, optional_actions=<value optimized 
out>, termios_p=0x62cb60)
      at ../sysdeps/unix/sysv/linux/tcsetattr.c:84
  84      retval = INLINE_SYSCALL (ioctl, 3, fd, cmd, &k_termios);
  (gdb) c
  Continuing.
  
  Program received signal SIGTTOU, Stopped (tty output).
  0x00000033f52dff48 in tcsetattr (fd=0, optional_actions=<value optimized 
out>, termios_p=0x62cb60)
      at ../sysdeps/unix/sysv/linux/tcsetattr.c:84
  84      retval = INLINE_SYSCALL (ioctl, 3, fd, cmd, &k_termios);
  (gdb) c
  Continuing.
  
  Program received signal SIGTTOU, Stopped (tty output).
  0x00000033f52dff48 in tcsetattr (fd=0, optional_actions=<value optimized 
out>, termios_p=0x62cb60)
      at ../sysdeps/unix/sysv/linux/tcsetattr.c:84
  84      retval = INLINE_SYSCALL (ioctl, 3, fd, cmd, &k_termios);
  (gdb) 
  
I have tried this with several different kernel versions, RHEL6, Fedora, RHEL7,
all with the same result.  The examples above are on a RHEL6 
2.6.32-537.el6.x86_64
kernel.

Unfortunately the behavior is intermittent.  Sometimes it does work as expected,
where both the parent bash shell and the crash or rl task are stopped, and when 
that happens, it seems to work all of the time.  But when it does start 
failing, 
it is repeatedly reproducible.

I'm hoping that you could try to reproduce it, and offer some suggestion as to
how to address it.

Thanks,
  Dave Anderson



reply via email to

[Prev in Thread] Current Thread [Next in Thread]