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

Closed
blueyed opened this Issue Jan 26, 2014 · 8 comments

Comments

Projects
None yet
2 participants
@blueyed
Contributor

blueyed commented Jan 26, 2014

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

This comment has been minimized.

Show comment
Hide comment
@joonty

joonty Jan 27, 2014

Collaborator

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.

Collaborator

joonty commented Jan 27, 2014

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

This comment has been minimized.

Show comment
Hide comment
@blueyed

blueyed Jan 27, 2014

Contributor

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.

Contributor

blueyed commented Jan 27, 2014

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

This comment has been minimized.

Show comment
Hide comment
@joonty

joonty Jan 27, 2014

Collaborator

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).

Collaborator

joonty commented Jan 27, 2014

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

This comment has been minimized.

Show comment
Hide comment
@blueyed

blueyed Jan 27, 2014

Contributor

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)

Contributor

blueyed commented Jan 27, 2014

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

This comment has been minimized.

Show comment
Hide comment
@blueyed

blueyed Jan 27, 2014

Contributor

@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.

Contributor

blueyed commented Jan 27, 2014

@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

This comment has been minimized.

Show comment
Hide comment
@blueyed

blueyed Jan 27, 2014

Contributor

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

Contributor

blueyed commented Jan 27, 2014

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 Jan 27, 2014

@blueyed

This comment has been minimized.

Show comment
Hide comment
@blueyed

blueyed Jan 27, 2014

Contributor

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

Contributor

blueyed commented Jan 27, 2014

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

@blueyed blueyed reopened this Jan 27, 2014

@joonty

This comment has been minimized.

Show comment
Hide comment
@joonty

joonty Jan 30, 2014

Collaborator

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!

Collaborator

joonty commented Jan 30, 2014

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 Jun 5, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment