vis crashes quite often on Ctrl-C

[mcepl]

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)

[ghost]

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

[mcepl]

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

[xomachine]

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.

[mcepl]

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.

[xomachine]

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?

[mcepl]

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.

[xomachine]

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.

[mcepl]

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.

[proskur1n]

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.

[xomachine]

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

1. Opening *.changes file and pressing Ctrl+C many times, switching between modes and pressing Ctrl+C
2. Opening multiple files, pressing Ctrl+C in various modes
3. 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.

[mcepl]

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

[mcepl]

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

[xomachine]

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.

[mcepl]

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.

[mcepl]

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)