Bug 1985 - vim hangs in signal handler
: vim hangs in signal handler
Status: CLOSED WONTFIX
: Sisyphus
(All bugs in Sisyphus/vim-enhanced)
: unstable
: all Linux
: P4 critical
Assigned To:
:
:
:
:
:
  Show dependency tree
 
Reported: 2003-01-16 19:41 by
Modified: 2005-07-13 15:45 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2003-01-16 19:41:26
Any vim linked with -lpthread (e.g. vim-enhanced or vim-X11) hangs on signal
receival in signal handler because of stack overflow endless loop.
---
1. run vim
2. send it SIGTERM
---
[<a href="mailto:user@localhost" target="_new">user@localhost</a> vim61]$
LD_LIBRARY_PATH=/usr/lib/debug gdb ./vim-enhanced
GNU gdb ALT Linux (5.2.1-alt2)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type \&quot;show copying\&quot; to see the conditions.
There is absolutely no warranty for GDB.  Type \&quot;show warranty\&quot; for
details.
This GDB was configured as \&quot;i586-alt-linux\&quot;...
(gdb) run
Starting program: /path/to/vim61/vim-enhanced 
[New Thread 1024 (LWP 8495)]
Program received signal SIGTERM, Terminated.
[Switching to Thread 1024 (LWP 8495)]
0x004cc01e in __select () at __select:-1
-1    __select: No such file or directory.
    in __select
(gdb) bt
#0  0x004cc01e in __select () at __select:-1
#1  0x0051e440 in __DTOR_END__ () from /usr/lib/debug/libc.so.6
#2  0x0810d5a2 in WaitForChar (msec=-1) at os_unix.c:3811
#3  0x0810b6f9 in mch_inchar (buf=0x822cc80 \&quot;\&quot;, maxlen=88,
wtime=-1) at os_unix.c:364
#4  0x081405a3 in ui_inchar (buf=0x822cc80 \&quot;\&quot;, maxlen=88, wtime=-1)
at ui.c:172
#5  0x080bdf2d in inchar (buf=0x822cc80 \&quot;\&quot;, maxlen=264,
wait_time=-1) at getchar.c:2650
#6  0x080bdc6a in vgetorpeek (advance=1) at getchar.c:2441
#7  0x080bc788 in vgetc () at getchar.c:1408
#8  0x080bcae3 in safe_vgetc () at getchar.c:1539
#9  0x080edd79 in normal_cmd (oap=0xbffff730, toplevel=1) at normal.c:592
#10 0x080c5ab0 in main_loop (cmdwin=0) at main.c:2051
#11 0x080c581a in main (argc=0, argv=0xbffff8f8) at main.c:1901
#12 0x00420582 in __libc_start_main (main=0x80c3ad4 &lt;main&gt;, argc=1,
ubp_av=0x0, init=0x8066ea4 &lt;_init&gt;, 
    fini=0x121a2c &lt;_dl_debug_mask&gt;, rtld_fini=0xbffff360, stack_end=0x0)
    at ../sysdeps/generic/libc-start.c:129
(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x0052d106 in pthread_sighandler (signo=15, ctx=
      {gs = 0, __gsh = 0, fs = 0, __fsh = 0, es = 43, __esh = 0, ds = 43, __dsh
= 0, edi = 0, esi = 3221222112, ebp = 3221222392, esp = 3221222048, ebx = 1,
edx = 0, ecx = 3221222240, eax = 4294967292, trapno = 1, err = 0, eip =
5029918, cs = 35, __csh = 0, eflags = 514, esp_at_signal = 3221222048, ss = 43,
__ssh = 0, fpstate = 0x8235a70, oldmask = 2147483648, cr2 = 0}) at signals.c:87
87      if (THREAD_GETMEM(self, p_sigwaiting)) {
(gdb) bt
#0  0x0052d106 in pthread_sighandler (signo=15, ctx=
      {gs = 0, __gsh = 0, fs = 0, __fsh = 0, es = 43, __esh = 0, ds = 43, __dsh
= 0, edi = 0, esi = 3221222112, ebp = 3221222392, esp = 3221222048, ebx = 1,
edx = 0, ecx = 3221222240, eax = 4294967292, trapno = 1, err = 0, eip =
5029918, cs = 35, __csh = 0, eflags = 514, esp_at_signal = 3221222048, ss = 43,
__ssh = 0, fpstate = 0x8235a70, oldmask = 2147483648, cr2 = 0}) at signals.c:87
#1  &lt;signal handler called&gt;
#2  0x004cc01e in __select () at __select:-1
#3  0x0051e440 in __DTOR_END__ () from /usr/lib/debug/libc.so.6
#4  0x0810d5a2 in WaitForChar (msec=-1) at os_unix.c:3811
#5  0x0810b6f9 in mch_inchar (buf=0x822cc80 \&quot;\&quot;, maxlen=88,
wtime=-1) at os_unix.c:364
#6  0x081405a3 in ui_inchar (buf=0x822cc80 \&quot;\&quot;, maxlen=88, wtime=-1)
at ui.c:172
#7  0x080bdf2d in inchar (buf=0x822cc80 \&quot;\&quot;, maxlen=264,
wait_time=-1) at getchar.c:2650
#8  0x080bdc6a in vgetorpeek (advance=1) at getchar.c:2441
#9  0x080bc788 in vgetc () at getchar.c:1408
#10 0x080bcae3 in safe_vgetc () at getchar.c:1539
#11 0x080edd79 in normal_cmd (oap=0xbffff730, toplevel=1) at normal.c:592
#12 0x080c5ab0 in main_loop (cmdwin=0) at main.c:2051
#13 0x080c581a in main (argc=0, argv=0xbffff8f8) at main.c:1901
#14 0x00420582 in __libc_start_main (main=0x80c3ad4 &lt;main&gt;, argc=1,
ubp_av=0x0, init=0x8066ea4 &lt;_init&gt;, 
    fini=0x121a2c &lt;_dl_debug_mask&gt;, rtld_fini=0xbffff360,
stack_end=0x83ffc00)
    at ../sysdeps/generic/libc-start.c:129
------- Comment #1 From 2003-01-17 18:54:18 -------
I have understood what is happening here. By default the LinuxThreads library
finds the current thread descriptor by the stack pointer value. However, vim
sets up an alternate signal stack, therefore pthread_self() gets some bogus
address instead of the thread descriptor. This does not happen with
glibc-core-i686, because it uses a different method for finding the current
thread descriptor.

So this is really a glibc problem - sigaltstack() does not work with the
default implementation of libpthread.
------- Comment #2 From 2003-01-17 18:54:18 -------
I have understood what is happening here. By default the LinuxThreads library
finds the current thread descriptor by the stack pointer value. However, vim
sets up an alternate signal stack, therefore pthread_self() gets some bogus
address instead of the thread descriptor. This does not happen with
glibc-core-i686, because it uses a different method for finding the current
thread descriptor.

So this is really a glibc problem - sigaltstack() does not work with the
default implementation of libpthread.
------- Comment #3 From 2003-09-24 19:51:21 -------
It's glibc problem - not vim.
------- Comment #4 From 2004-05-17 03:06:37 -------
Unable to reproduce with glibc-2.3.3+, looks like fixed.