Linux dialog consuming 100% CPU in the broken session

Question

when I'm using /usr/bin/dialog by ssh (PuTTY from windows) for example:

dialog --ok-label Select --cancel-label Cancel --stdout --backtitle BACKTITLE --menu TITLE 0 50 0 '1' 'alfa' '2' 'beta'

and when the dialog is displayed, I close my putty by Alt-F4 (or mouse click on X) dialog process not exit but exists and get 100% CPU:

PID  USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
9928 user      20   0  113m 2308 1092 R 100.0  0.0   0:30.99 dialog

Bellow is my gdb session:

$ gdb -p 9928
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-56.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 9928
Reading symbols from /usr/bin/dialog...(no debugging symbols found)...done.
Reading symbols from /usr/lib64/libdialog.so.6...(no debugging symbols found)...done.
Loaded symbols for /usr/lib64/libdialog.so.6
Reading symbols from /lib64/libncursesw.so.5...(no debugging symbols found)...done.
Loaded symbols for /lib64/libncursesw.so.5
Reading symbols from /lib64/libm.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib64/libm.so.6
Reading symbols from /lib64/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib64/libc.so.6
Reading symbols from /lib64/libtinfo.so.5...(no debugging symbols found)...done.
Loaded symbols for /lib64/libtinfo.so.5
Reading symbols from /lib64/libdl.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib64/libdl.so.2
Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
Reading symbols from /usr/lib64/gconv/ISO8859-2.so...(no debugging symbols found)...done.
Loaded symbols for /usr/lib64/gconv/ISO8859-2.so
0x00007f902081e315 in fcntl () from /lib64/libc.so.6
Missing separate debuginfos, use: debuginfo-install dialog-1.1-9.20080819.1.el6.x86_64
(gdb) bt
#0  0x00007f902081e315 in fcntl () from /lib64/libc.so.6
#1  0x00007f9020fa3b5d in ?? () from /usr/lib64/libdialog.so.6
#2  0x00007f9020fa4230 in dlg_getc () from /usr/lib64/libdialog.so.6
#3  0x00007f9020fa15a3 in ?? () from /usr/lib64/libdialog.so.6
#4  0x00007f9020fa0668 in dlg_menu () from /usr/lib64/libdialog.so.6
#5  0x00007f9020fa131c in dialog_menu () from /usr/lib64/libdialog.so.6
#6  0x0000000000403916 in ?? ()
#7  0x000000000040415c in ?? ()
#8  0x00007f9020761cdd in __libc_start_main () from /lib64/libc.so.6
(gdb) continue
Continuing.
^C
Program received signal SIGINT, Interrupt.
0x00007f902081de00 in __read_nocancel () from /lib64/libc.so.6
(gdb) bt
#0  0x00007f902081de00 in __read_nocancel () from /lib64/libc.so.6
#1  0x00007f9020d6a277 in _nc_wgetch () from /lib64/libncursesw.so.5
#2  0x00007f9020d7f430 in wget_wch () from /lib64/libncursesw.so.5
#3  0x00007f9020fa401f in dlg_getc () from /usr/lib64/libdialog.so.6
#4  0x00007f9020fa15a3 in ?? () from /usr/lib64/libdialog.so.6
#5  0x00007f9020fa0668 in dlg_menu () from /usr/lib64/libdialog.so.6
#6  0x00007f9020fa131c in dialog_menu () from /usr/lib64/libdialog.so.6
#7  0x0000000000403916 in ?? ()
#8  0x000000000040415c in ?? ()
#9  0x00007f9020761cdd in __libc_start_main () from /lib64/libc.so.6

Any ideas what should I do? Now I have task in cron which finds old dialogs and kills them.

You don't tell what the version of dialog is. That symptom matches a few old bug reports (which presumably were fixed). — Thomas Dickey, Apr 11 '15 at 01:07
My `dialog` id default in CentOS 6.5. `Version: 1.1-20080819` — Krzysztof Szewczyk, Apr 13 '15 at 05:55

score 2 · Accepted Answer · answered Apr 13 '15 at 08:22

The given version 1.1-20080819 is old. For instance a related problem was fixed in 2009/02/22:

modify dlg_result_key() to map curses ERR to dialog's error exit (adapted from patch by Domagoj Pensa).

which in turn was an improvement on a change made in 2007/07/04:

add a check when ERR returned from wgetch() to ensure that the input/output streams are still valid. If that happens, force ESC to be returned, quitting dialog (report by Reiner Huober).

At the moment, the current version is 1.2-20150225.

score 1 · Answer 2 · answered Apr 13 '15 at 06:31

1

Compilation the newest dialog resolved my problem. I had 1.1-20080819 dialog version while now I have 1.2-20140911 where problem is resolved.
@ThomasDickey thanks for suggestion.

answered Apr 13 '15 at 06:31

Krzysztof Szewczyk

1,752
1
21
25

Linux dialog consuming 100% CPU in the broken session

2 Answers2