Skip to content

Loading…

Vim segfaults on Ctrl-C during input polling on startup #134

Closed
blueyed opened this Issue · 8 comments

2 participants

@blueyed

I have noticed that Vim segfaults on Ctrl-C during "Waiting for a connection (Ctrl-C to cancel, this message will self-destruct in 20 seconds...)".

Can you confirm this?

(using Vim master / tip)

@joonty
Owner

This doesn't sound right at all. Does it happen every time, consistently?

I haven't seen this on various patch level versions of 7.3/7.4, but I haven't updated in a few months. I'll try updating to master too.

@blueyed

Yes, constantly:

(gdb) bt
#0  __GI___libc_free (mem=0x65740029656d0074) at malloc.c:2892
#1  0x000000000050b518 in vim_free (x=0x65740029656d0074) at misc2.c:1744
#2  0x00000000004a5ff4 in discard_exception (excp=0x13c2b50, was_finished=0) at ex_eval.c:643
#3  0x00000000004a601f in discard_current_exception () at ex_eval.c:653
#4  0x000000000061977e in VimTryEnd () at if_py_both.h:562
#5  0x000000000061a201 in VimEval (self=0x0, args=0x1c250d0) at if_py_both.h:820
#6  0x00007fffef7abad4 in PyEval_EvalFrameEx () from /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0
#7  0x00007fffef7aba59 in PyEval_EvalFrameEx () from /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0
#8  0x00007fffef7aba59 in PyEval_EvalFrameEx () from /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0
#9  0x00007fffef7aba59 in PyEval_EvalFrameEx () from /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0
#10 0x00007fffef7adb4d in PyEval_EvalCodeEx () from /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0
#11 0x00007fffef7adce0 in ?? () from /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0
#12 0x00007fffef799483 in PyObject_Call () from /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0
#13 0x00007fffef719a7d in ?? () from /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0
#14 0x00007fffef799483 in PyObject_Call () from /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0
#15 0x00007fffef777dc7 in PyEval_CallObjectWithKeywords () from /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0
#16 0x00007fffef6bf818 in PyInstance_New () from /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0
#17 0x00007fffef799483 in PyObject_Call () from /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0
#18 0x00007fffef7a9216 in PyEval_EvalFrameEx () from /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0
#19 0x00007fffef7aba59 in PyEval_EvalFrameEx () from /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0
#20 0x00007fffef7aba59 in PyEval_EvalFrameEx () from /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0
#21 0x00007fffef7aba59 in PyEval_EvalFrameEx () from /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0
#22 0x00007fffef7aba59 in PyEval_EvalFrameEx () from /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0
#23 0x00007fffef7adb4d in PyEval_EvalCodeEx () from /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0
#24 0x00007fffef7ade32 in PyEval_EvalCode () from /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0
#25 0x00007fffef6da5c9 in PyRun_StringFlags () from /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0
#26 0x000000000062275e in run_cmd (cmd=0x16a8ee7 "debugger.run()", arg=0x7fffffffb150, pygilstate=0x7fffffffb054) at if_py_both.h:5052
#27 0x000000000062588d in DoPyCommand (cmd=0x16a8ee7 "debugger.run()", init_range=0x6226d8 <init_range_cmd>, run=0x62272a <run_cmd>, 
    arg=0x7fffffffb150) at if_python.c:1023

So if it does not happen for you, I might look into it again to find the cause of it. From the gdb backtrace it might be related to exception handling.
Also, another Vim plugin might be involved.

@joonty
Owner

Having said that I haven't experienced it, I've just seen it happen!

It doesn't happen constantly for me, however. Also, I'd never seen it before today. The only thing that has been added is the sleep statement, from your good self. I don't see how this could possibly cause a segfault, but perhaps it's worth taking this out on your end and seeing whether the segfaults continue (unless you were already getting them before, of course).

@blueyed

I could now track it down to the following vimrc (run it with vim -u vimrc):

set nocp
set rtp=./bundle/vdebug

" From easytags: this try block triggers a segfault when Ctrl-C'ing
" vdebug's VdebugStart.
try
  " The point of this code is to do something completely innocent while making
  " sure the vim-misc plug-in is installed. We specifically don't use Vim's
  " exists() function because it doesn't load auto-load scripts that haven't
  " already been loaded yet (last tested on Vim 7.3).
  call type(g:xolox#misc#version)
catch
  echomsg "try failed"
endtry

Then call VdebugStart and Ctrl-C it.

Can you reproduce it this way?

(It does not matter (for me) if there's the sleep statement in the poll loop)

@blueyed

@joonty
Here is a vimrc file that does not crash, but results in a "Invalid pointer" error:

set nocp
" set rtp=./bundle/vdebug
"
" From easytags: this try block triggers a segfault when Ctrl-C'ing
" vdebug's VdebugStart.
try
  " The point of this code is to do something completely innocent while making
  " sure the vim-misc plug-in is installed. We specifically don't use Vim's
  " exists() function because it doesn't load auto-load scripts that haven't
  " already been loaded yet (last tested on Vim 7.3).
  call type(g:xolox#misc#version)
catch
  " echomsg "try failed"
endtry


python << EOF
import time, vim
def eval_loop_getchar():
        try:
                while True:
                        vim.eval('getchar(0)')
                        time.sleep(0.5)
        except Exception as e:
                print e
EOF

fun! CrashOnCtrlC()
        python eval_loop_getchar()
endfunction

" Crashes on Ctrl-C
command! EvalLoop python eval_loop_getchar()

After :EvalLoop, pressing Ctrl-C results in:

*** Error in `vim': munmap_chunk(): invalid pointer: 0x00007fc6496dc9c8 ***

And Vim needs to be killed using SIGKILL (kill -9).

Another variant of this also triggered a segfault, like when using easytags and vdebug. That was likely when the eval loop was executed directly, without being wrapped in a Python function.

@blueyed

Since it is a bug in Vim, I have posted to vim_dev and will close this issue.

https://groups.google.com/d/msg/vim_dev/_isQkYhokdA/t6iRMSrSI_AJ

@blueyed blueyed closed this
@blueyed

OTOH: re-open, because a workaround might be appropriate for vdebug.

@blueyed blueyed reopened this
@joonty
Owner

Ok, thanks for all the detail on that.

I don't know whether I'm going to spend time on a workaround, mainly because I'm working on version 2 which introduces a background listener (see #19), as opposed to the existing blocking approach. Hopefully that will be the preferred method.

Also, good to see that a patch was made as a result!

@joonty joonty closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.