100% CPU load by a Vifm that should have closed

[aleksejrs]

0.8.1a

Sometimes I notice one or two vifm processes loading the CPU.

Every time it happened it was at night, and right now the processes belonged to the user that had the duplicated filetype in vifminfo problem. I closed that user's session hours ago.

[xaizek]

Not sure how vifminfo would relate to loading the CPU, might be a coincidence. Depending on how it was closed maybe it appeared to the application that terminal didn't hang. That would be strange as it seems to work in general, but still possible. You could try attaching to that process via gdb (gdb -p <pid>) and generating a backtrace ((gdb) bt), that should at least show where it hangs. Normally when controlling terminal isn't available, vifm exits.

[aleksejrs]

(see steps to reproduce in the next comment)

…
0x00007f0743956b47 in access () at ../sysdeps/unix/syscall-template.S:81
81  ../sysdeps/unix/syscall-template.S: No such file or directory.
(gdb) bt
#0  0x00007f0743956b47 in access () at ../sysdeps/unix/syscall-template.S:81
#1  0x000000000044f5e5 in  ()
#2  0x000000000044c4a4 in  ()
#3  0x0000000000405335 in  ()
#4  0x00007f074389b870 in __libc_start_main (main=
    0x405000, argc=1, argv=0x7ffe00522858, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffe00522848)
    at libc-start.c:291
#5  0x0000000000405499 in  ()
(gdb) 

…
done.
0x00007f0743956a90 in __read_nocancel () at ../sysdeps/unix/syscall-template.S:81
81  ../sysdeps/unix/syscall-template.S: No such file or directory.
(gdb) bt
#0  0x00007f0743956a90 in __read_nocancel () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007f07438eed00 in _IO_new_file_underflow (fp=0x185fbe0) at fileops.c:580
#2  0x00007f07438edfe8 in __GI__IO_file_xsgetn (fp=0x185fbe0, data=<optimized out>, n=4) at fileops.c:1402
#3  0x00007f07438e3e60 in __GI__IO_fread (buf=<optimized out>, size=4, count=1, fp=0x185fbe0) at iofread.c:42
#4  0x000000000045ad50 in  ()
#5  0x000000000044c215 in  ()
#6  0x0000000000405335 in  ()
#7  0x00007f074389b870 in __libc_start_main (main=
    0x405000, argc=1, argv=0x7ffe00522858, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffe00522848)
    at libc-start.c:291
#8  0x0000000000405499 in  ()

done.
0x00007f074395aa80 in __poll_nocancel () at ../sysdeps/unix/syscall-template.S:81
81  ../sysdeps/unix/syscall-template.S: No such file or directory.
(gdb) bt
#0  0x00007f074395aa80 in __poll_nocancel () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007f07462d0c95 in _nc_timed_wait (__timeout=15, __nfds=<optimized out>, __fds=0x7ffe00521240)
    at /usr/include/x86_64-linux-gnu/bits/poll2.h:41
#2  0x00007f07462d0c95 in _nc_timed_wait (sp=sp@entry=0x186c0c0, mode=mode@entry=3, milliseconds=15, timeleft=timeleft@entry=0x0)
    at /build/ncurses-omz7Vm/ncurses-6.0+20151024/ncurses/tty/lib_twait.c:266
#3  0x00007f07464f38d8 in _nc_wgetch (delay=<optimized out>, sp=0x186c0c0)
    at /build/ncurses-omz7Vm/ncurses-6.0+20151024/ncurses/base/lib_getch.c:165
#4  0x00007f07464f38d8 in _nc_wgetch (win=win@entry=0x18f7c50, result=result@entry=0x7ffe005213c8, use_meta=use_meta@entry=1)
    at /build/ncurses-omz7Vm/ncurses-6.0+20151024/ncurses/base/lib_getch.c:510
#5  0x00007f074650921b in wget_wch (win=0x18f7c50, result=0x7ffe005214d4)
    at /build/ncurses-omz7Vm/ncurses-6.0+20151024/ncurses/widechar/lib_get_wch.c:70
#6  0x000000000044c240 in  ()
#7  0x0000000000405335 in  ()
#8  0x00007f074389b870 in __libc_start_main (main=
    0x405000, argc=1, argv=0x7ffe00522858, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffe00522848)
    at libc-start.c:291
#9  0x0000000000405499 in  ()
(gdb) 

[aleksejrs]

Reproduced:

1. start GNOME Terminal 3.18.2.
2. start vifm from it.
3. press “s” to run a shell.
4. start another vifm from that shell.
   (optionally: repeat steps 3-4 to get more vifms to stay running)
5. close the terminal window (apparently not a tab).

[xaizek]

Thank you. It really seems that vifm was unable to determine that terminal isn't available anymore. I'm able to reproduce it with gnome-terminal as well, hope this can be fixed unlike other problems with it (vifm/vifm.vim#2).