Bug 1985

Summary: vim hangs in signal handler
Product: Sisyphus Reporter: Dmitry V. Levin <ldv>
Component: vim-enhancedAssignee: Gleb F-Malinovskiy <glebfm>
Status: CLOSED WONTFIX QA Contact: qa-sisyphus
Severity: critical    
Priority: P4 CC: admsasha, glebfm, ldv, vsu
Version: unstable   
Hardware: all   
OS: Linux   

Description Dmitry V. Levin 2003-01-16 19:41:26 MSK
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 Sergey Vlasov 2003-01-17 18:54:18 MSK
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 Sergey Vlasov 2003-01-17 18:54:18 MSK
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 Sir Raorn 2003-09-24 19:51:21 MSD
It's glibc problem - not vim.
Comment 4 Dmitry V. Levin 2004-05-17 03:06:37 MSD
Unable to reproduce with glibc-2.3.3+, looks like fixed.