Version-Release number of selected component:
cmdline: vim mcelog.service
runlevel: N 5
Thread no. 1 (10 frames)
#16 vim_handle_signal at os_unix.c:1521
#17 ui_inchar at ui.c:166
#18 inchar at getchar.c:3521
#19 vgetorpeek at getchar.c:3300
#20 vgetc at getchar.c:1689
#21 safe_vgetc at getchar.c:1918
#22 normal_cmd at normal.c:570
#23 main_loop at main.c:1478
#24 vim_main2 at main.c:868
Created attachment 1722593 [details]
Created attachment 1722594 [details]
Created attachment 1722595 [details]
Created attachment 1722596 [details]
Created attachment 1722597 [details]
Created attachment 1722598 [details]
Created attachment 1722599 [details]
Created attachment 1722600 [details]
Created attachment 1722601 [details]
Created attachment 1722602 [details]
Created attachment 1722603 [details]
Created attachment 1722604 [details]
thank you for reporting the issue!
Are you able to reproduce the issue?
If I understand correctly the backtrace, Vim got SIGHUP and 'vim_handle_signal()' is called as a part of dealing with signals. 'vim_handle_signal()' went well with this signal number as the argument and set 'got_signal' value to '1'.
In the next 'vim_handle_signal()' invocation, when it is called from 'ui_inchar()', it got an segfault on 'kill()'.
I tried to reproduce it with sending SIGHUP via 'kill' to opened 'vim', but without success.
I don't know what caused it, sorry. I don't even remember any vim process crashing or being killed. I just found the report in the abrt client and thought I'd report it.
Feel free to close it if you can't reproduce it.
Ok, then I'll close it for now. Feel free to reopen if you hit it again.
Ah, I've just realised that this probably happened when I switched network and an ssh connection was closed, sending SIGHUP to the vim process running on the remote host.
I'll reopen if I see it again. Thanks.