vis crashes quite often on Ctrl-C

Question

vis crashes quite often on Ctrl-C

mcepl opened this issue 2 years ago · comments

Using the latest vis from the master (particularly 1a958f2, but the situation has been the same for some time already) with couple of patches from unmerged pull requests here (see openSUSE project for the complete list), vis crashes on me quite often, when I press Ctrl-C while editing. The backtrace I found is (which is not much useful, right?):

(gdb) t a a bt

Thread 1 (Thread 0x7ffff7b19380 (LWP 18159) "vis"):
#0  pselect64_syscall (sigmask=0x7fffffffbd60, timeout=<optimized out>, exceptfds=0x0, writefds=0x0, readfds=0x7fffffffbe80, nfds=1) at ../sysdeps/unix/sysv/linux/pselect.c:35
#1  __pselect (nfds=1, readfds=0x7fffffffbe80, writefds=0x0, exceptfds=0x0, timeout=<optimized out>, sigmask=0x7fffffffbd60) at ../sysdeps/unix/sysv/linux/pselect.c:57
#2  0x000055555558ad44 in vis_run (vis=0x5555555b7cb0) at /usr/src/debug/vis-0.7+git.1618946717.1a958f2-24.1.x86_64/vis.c:1416
#3  0x0000555555568cd9 in main (argc=2, argv=0x7fffffffd278) at /usr/src/debug/vis-0.7+git.1618946717.1a958f2-24.1.x86_64/main.c:2351
(gdb)

Deleted user · Answer 1 · Sun Nov 21 2021 18:19:07 GMT+0800 (China Standard Time)

with couple of patches from unmerged pull requests here (see openSUSE project for the complete list)

I think the culprit might be 675-non-block_subproc.patch, as it touches exactly the pselect line in vis.c that is part of the stack trace:

#1  __pselect (nfds=1, readfds=0x7fffffffbe80, writefds=0x0, exceptfds=0x0, timeout=<optimized out>, sigmask=0x7fffffffbd60) at ../sysdeps/unix/sysv/linux/pselect.c:57
#2  0x000055555558ad44 in vis_run (vis=0x5555555b7cb0) at /usr/src/debug/vis-0.7+git.1618946717.1a958f2-24.1.x86_64/vis.c:1416

Matěj Cepl · Answer 2 · Sun Nov 21 2021 19:04:16 GMT+0800 (China Standard Time)

OK, so just to mention #675 and that it seems to be crashing vis.

Dmitriy Fomichev · Answer 3 · Sun Nov 21 2021 20:53:24 GMT+0800 (China Standard Time)

I tried the version of vis from the build service with all patches applied, but was not able to reproduce the issue.

Could you provide a bit more information about the environment? In particular a list of plugins that is active when the problem occurs, the file which is opened (if any) or step by step instruction about what exactly should be performed.

Also when debugging in gdb it is natural to stop the program via Ctrl+C and the stack trace will be pointing at pselect, since it is the place where vis idling. To avoid this happening pass to gdb the following line handle SIGINT noprint nostop pass and then run the program.

Matěj Cepl · Answer 4 · Sun Nov 21 2021 20:57:10 GMT+0800 (China Standard Time)

I tried the version of vis from the build service with all patches applied, but was not able to reproduce the issue.

I don’t have reliable way how to reproduce it either. It just sometimes happen, mostly when I edit *.changes file.

Could you provide a bit more information about the environment? In particular a list of plugins that is active when the problem occurs, the file which is opened (if any) or step by step instruction about what exactly should be performed.

Yes, there are plenty of plugins:

python-mkdocs-bootstrap@stitny$ l ~/.config/vis/plugins/
celkem 0
drwxr-xr-x. 1 matej users 404 10. čec 13.16 ./
drwxr-xr-x. 1 matej users 114 18. lis 20.50 ../
drwxr-xr-x. 1 matej users  56  6. lis 23.24 vis-commentary/
drwxr-xr-x. 1 matej users  76  7. říj 17.40 vis-cursors/
drwxr-xr-x. 1 matej users  88  6. lis 23.24 vis-editorconfig/
drwxr-xr-x. 1 matej users  56 16. led  2021 vis-filetype-settings/
drwxr-xr-x. 1 matej users  56 13. dub  2021 vis-fzf-open/
drwxr-xr-x. 1 matej users  56 17. bře  2021 vis-git-status/
drwxr-xr-x. 1 matej users  46  2. říj 12.02 vis-goto-file/
drwxr-xr-x. 1 matej users  84 10. čec 13.18 vis-jump/
drwxr-xr-x. 1 matej users  58 13. pro  2020 vis-open_rej/
drwxr-xr-x. 1 matej users  24  2. říj 12.02 vis-pairs/
drwxr-xr-x. 1 matej users  78 10. čec 13.16 vis-par/
drwxr-xr-x. 1 matej users  56 23. zář  2020 vis-smart-backspace/
drwxr-xr-x. 1 matej users  58  4. kvě  2020 vis-snippets/
drwxr-xr-x. 1 matej users 136  7. říj 17.41 vis-spellcheck/
drwxr-xr-x. 1 matej users  56 12. úno  2021 vis-title/
drwxr-xr-x. 1 matej users  48 10. čec 13.16 vis-toggler/
python-mkdocs-bootstrap@stitny$

Also when debugging in gdb it is natural to stop the program via Ctrl+C and the stack trace will be pointing at pselect, since it is the place where vis idling. To avoid this happening pass to gdb the following line handle SIGINT noprint nostop pass and then run the program.

No, I didn’t stop it. Just started vis in gdb and let it run until it crashed on its own.

Dmitriy Fomichev · Answer 5 · Sun Nov 21 2021 21:02:17 GMT+0800 (China Standard Time)

Just started vis in gdb and let it run until it crashed on its own.

Does it mean that the crash occurs without pressing Ctrl+C or anything as well?

Matěj Cepl · Answer 6 · Sun Nov 21 2021 21:03:59 GMT+0800 (China Standard Time)

Just started vis in gdb and let it run until it crashed on its own.

Does it mean that the crash occurs without pressing Ctrl+C or anything as well?

Well, pressing Ctrl-C inside of the running vis, but it happens even when vis is outside of gdb. Sometime. I am really not able to reproduce it reliably.

Dmitriy Fomichev · Answer 7 · Sun Nov 21 2021 21:12:35 GMT+0800 (China Standard Time)

May I get the plugins folder and the core dump file from the crash without gdb? I'm afraid I won't be able to collect all those plugins with their exact versions that is used in your installation.

Matěj Cepl · Answer 8 · Mon Nov 22 2021 06:49:26 GMT+0800 (China Standard Time)

May I get the plugins folder and the core dump file from the crash without gdb? I'm afraid I won't be able to collect all those plugins with their exact versions that is used in your installation.

vis.zip is the ~/.config/vis/ directory
relevant part of .gitmodules of the parent directory of ~/.config/vis.

I have hard time to generate plain core dumps on my openSUSE, I have to investigate what's going on.

Andrey Proskurin · Answer 9 · Thu Nov 25 2021 18:39:12 GMT+0800 (China Standard Time)

Just wanted to say that my soft-word-wrapping patch #948 sometimes segfaults on binary files. I haven't spent too much time debugging this issue yet, since I don't use vis as my primary editor anymore. I don't think that it is related to your problem. However, it is something to keep in mind.

Dmitriy Fomichev · Answer 10 · Sat Nov 27 2021 22:38:48 GMT+0800 (China Standard Time)

I've tried multiple scenarios with provided plugins, but none of them caused SIGSEGV in vis. My attempts were:

Opening *.changes file and pressing Ctrl+C many times, switching between modes and pressing Ctrl+C
Opening multiple files, pressing Ctrl+C in various modes
Pressing Ctrl+C while doing search and typing :command

Moreover, I noticed that those plugins don't use subprocess Lua API. So I have to ask: are those crashes fixed after removing subprocess patch from a build process? If so - I guess that only core dump can help me to figure out what is going on.

Matěj Cepl · Answer 11 · Fri Dec 10 2021 06:16:23 GMT+0800 (China Standard Time)

Seems like when I removed 675-non-block_subproc.patch (from #675) I cannot reproduce a crash.

Matěj Cepl · Answer 12 · Fri Dec 31 2021 02:09:21 GMT+0800 (China Standard Time)

OK, back with the patch, and reproducing the issue again. Actually, it seems the Ctrl-C has to happen with the active selection.

Dmitriy Fomichev · Answer 13 · Fri Dec 31 2021 15:52:59 GMT+0800 (China Standard Time)

Still can not reproduce even with active selection or multiple selections. It might be related to OS, since I am performing the test on Arch, and it seems like your case is related to OpenSUSE.

I need to take a look at the core dump file to figure out what exactly went wrong.

Matěj Cepl · Answer 14 · Tue Jul 12 2022 23:21:51 GMT+0800 (China Standard Time)

OK, this is going nowhere, and I would like #675 to be merged so let’s close this one and I will open new ticket when i am able to find out more about it.

Matěj Cepl · Answer 15 · Wed Aug 03 2022 01:26:36 GMT+0800 (China Standard Time)

Hmm, this is still continuing (with 33fdd28 commit and added patches):

Program received signal SIGINT, Interrupt.
0x00007f398c7b7393 in pselect () from /lib64/libc.so.6
(gdb) t a a bt

Thread 1 (Thread 0x7f398c4deec0 (LWP 17630) "vis"):
#0  0x00007f398c7b7393 in pselect () from /lib64/libc.so.6
#1  0x00005610ba11ac82 in vis_run (vis=0x5610ba537cb0) at /usr/src/debug/vis-0.7+git.1658823525.33fdd28-6.2.x86_64/vis.c:1433
#2  0x00005610ba0f8ce8 in main (argc=3, argv=0x7ffc2847ff28) at /usr/src/debug/vis-0.7+git.1658823525.33fdd28-6.2.x86_64/main.c:2351
(gdb)