#7 nwipe not getting killed and increasing cpu usage to 99%

closed
nobody
None
5
2012-08-10
2012-08-03
Michal Ambroz
No

This bug has been reported to Fedora by Michael Schwendt.
https://bugzilla.redhat.com/show_bug.cgi?id=836957

When nwipe is started in virtual terminal (like gnome-terminal) and the terminal gets closed the nwipe is reacting in a strange way.
Instead of closing gracefully it gets trapped in infinite loop trying to print to the terminal increasing dramatically the CPU usage (not wiping, just trying to print some error message).
Issue seems to be in handling of the SIGTSTP signal when there is no access to the terminal to write to.

To reproduce:
1) login to GUI with normal account
2) open terminal (tested with xterm, gnome-terminal)
3) sudo su - root
4) nwipe
5) close the terminal

This is output from strace:
Process 10061 attached
rt_sigaction(SIGTSTP, {SIG_IGN, [], SA_RESTORER|SA_RESTART, 0x3f7720efe0}, {0x3f8da15750, [], SA_RESTORER|SA_RESTART, 0x3f7720efe0}, 8) = 0
write(1, "\33[9;55H", 7) = -1 EIO (Input/output error)
rt_sigaction(SIGTSTP, {0x3f8da15750, [], SA_RESTORER|SA_RESTART, 0x3f7720efe0}, NULL, 8) = 0
rt_sigaction(SIGTSTP, {SIG_IGN, [], SA_RESTORER|SA_RESTART, 0x3f7720efe0}, {0x3f8da15750, [], SA_RESTORER|SA_RESTART, 0x3f7720efe0}, 8) = 0
write(1, "\33[51;87H", 8) = -1 EIO (Input/output error)
rt_sigaction(SIGTSTP, {0x3f8da15750, [], SA_RESTORER|SA_RESTART, 0x3f7720efe0}, NULL, 8) = 0
rt_sigaction(SIGTSTP, {SIG_IGN, [], SA_RESTORER|SA_RESTART, 0x3f7720efe0}, {0x3f8da15750, [], SA_RESTORER|SA_RESTART, 0x3f7720efe0}, 8) = 0
write(1, "\33[2;27H", 7) = -1 EIO (Input/output error)

This is backtrace:
Thread 2 (Thread 0x7fb751a6a700 (LWP 3230)):
#0 do_sigwait (sig=0x7fb751a69d0c, set=<optimized out>)
at ../sysdeps/unix/sysv/linux/sigwait.c:65
#1 __sigwait (set=set@entry=0x7fb751a69d10, sig=sig@entry=0x7fb751a69d0c)
at ../sysdeps/unix/sysv/linux/sigwait.c:100
#2 0x0000000000403377 in signal_hand (ptr=<optimized out>) at nwipe.c:499
#3 0x0000003e72c07d14 in start_thread (arg=0x7fb751a6a700)
at pthread_create.c:309
#4 0x0000003e728f199d in clone ()
at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115

Thread 1 (Thread 0x7fb751a6b840 (LWP 3213)):
#0 0x0000003e72878eda in _IO_default_xsputn (f=0x7fff1bce73a0,
data=<optimized out>, n=8) at genops.c:480
#1 0x0000003e7284636a in _IO_vfprintf_internal (s=s@entry=0x7fff1bce73a0,
format=format@entry=0x409ab1 " [ ] %i. %s (%lld bytes)",
ap=ap@entry=0x7fff1bce7548) at vfprintf.c:1285
#2 0x0000003e72907040 in ___vsnprintf_chk (
s=0x1f433a0 " [ ] 7. Linux device-mapper (linear) (21474836480 bytes)",
maxlen=<optimized out>, flags=flags@entry=1,
slen=slen@entry=18446744073709551615,
format=format@entry=0x409ab1 " [ ] %i. %s (%lld bytes)",
args=args@entry=0x7fff1bce7548) at vsnprintf_chk.c:65
#3 0x0000003e87816da9 in vsnprintf (__ap=0x7fff1bce7548,
__fmt=0x409ab1 " [ ] %i. %s (%lld bytes)", __n=<optimized out>,
__s=<optimized out>) at /usr/include/bits/stdio2.h:78
#4 _nc_printf_string (fmt=0x409ab1 " [ ] %i. %s (%lld bytes)",
ap=ap@entry=0x7fff1bce7548) at ../../ncurses/base/safe_sprintf.c:258
#5 0x0000003e8781268f in vwprintw (win=0x1f45380, fmt=<optimized out>,
argp=argp@entry=0x7fff1bce7548) at ../../ncurses/base/lib_printw.c:137
#6 0x0000003e87812897 in wprintw (win=<optimized out>,
fmt=fmt@entry=0x409ab1 " [ ] %i. %s (%lld bytes)")
at ../../ncurses/base/lib_printw.c:78
#7 0x0000000000404fb7 in nwipe_gui_select (count=count@entry=14, c=0x1f34420)
at gui.c:452
#8 0x0000000000402465 in main (argc=<optimized out>, argv=<optimized out>)
at nwipe.c:204

Best regards
Michal Ambroz

Discussion

  • Andy Beverley
    Andy Beverley
    2012-08-06

    I have found and fixed the problem related to this bug. However, before I release the fix, I would like to also look at what happens when a terminal window is closed during a wipe, as a similar thing happens. I will release a new version shortly.

     
  • Andy Beverley
    Andy Beverley
    2012-08-06

    Excellent bug report by the way - very easy to find the problem!

     
  • Andy Beverley
    Andy Beverley
    2012-08-10

    Fixed in v0.10.

     
  • Andy Beverley
    Andy Beverley
    2012-08-10

    • status: open --> closed