Segfault on ~

[niemeyer]

Whenever the ~ character is typed:

niemeyer@gopher ~> fish
niemeyer@gopher ~> ~fish: Job 1, 'fish' terminated by signal SIGSEGV (Address boundary error)

[niemeyer]

That's with the latest fish_fish branch (as of right now), by the way.

[niemeyer]

Backtrace:

(gdb) bt
#0  0x00007faed4d42cdd in get_nprocs () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007faed4cd0bca in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x00007faed4cd4b79 in malloc () from /lib/x86_64-linux-gnu/libc.so.6
#3  0x00007faed4cc0c9b in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#4  0x00007faed522baa3 in ?? () from /lib/x86_64-linux-gnu/libnss_compat.so.2
#5  0x00007faed522cba6 in _nss_compat_setpwent () from /lib/x86_64-linux-gnu/libnss_compat.so.2
#6  0x000000000055818b in __nss_setent ()
#7  0x000000000054d523 in setpwent ()
#8  0x00000000004189ce in completer_t::try_complete_user (this=0x7faed3d11a00, str=...) at complete.cpp:1637
#9  0x000000000041e2ac in complete (cmd=..., comps=..., type=<optimized out>, commands_to_load=0x21b9fa0) at complete.cpp:1723
#10 0x0000000000457fff in autosuggestion_context_t::threaded_autosuggest (this=0x21b9e90) at reader.cpp:1294
#11 0x0000000000451ea9 in threaded_autosuggest (ctx=<optimized out>) at reader.cpp:1307
#12 0x0000000000481d89 in iothread_worker (threadPtr=0x828550) at iothread.cpp:110
#13 0x000000000048db5a in start_thread (arg=0x7faed3d12700) at pthread_create.c:308
#14 0x00000000005557d9 in clone ()
#15 0x0000000000000000 in ?? ()

[siteshwar]

It doesn't crash for me. BTW I see your logs, you are on a 64 bit system and I am using 32 bit system.

[niemeyer]

I'm probably doing something it doesn't like, as I'm installing my own copy of fish at $HOME/bin. The backtrace above isn't very reassuring, though. It's breaking within a function of the C library which doesn't really take any parameters, which smells as a race with something unrelated.

[ridiculousfish]

It might be a thread safety issue.

[ridiculousfish]

Are you sure that's the crashing thread? Please attach the backtrace of all threads - even if that is the crashing threads, knowing what other threads are doing could help.

Thanks.

[niemeyer]

(gdb) thread apply all backtrace

Thread 2 (Thread 0x23a5880 (LWP 12430)):
#0  0x00000000005528d7 in select ()
#1  0x000000000046fa5f in readb () at input_common.cpp:102
#2  input_common_readch (timed=<optimized out>) at input_common.cpp:217
#3  0x0000000000465051 in input_try_mapping (m=...) at input.cpp:450
#4  input_readch () at input.cpp:514
#5  0x0000000000455671 in reader_readline () at reader.cpp:2691
#6  0x0000000000457994 in read_i () at reader.cpp:2570
#7  reader_read (fd=<optimized out>, io=<optimized out>) at reader.cpp:3447
#8  0x0000000000402e1e in main (argc=1, argv=0x7fff9dc1eec8) at fish.cpp:324

Thread 1 (Thread 0x7f6f99433700 (LWP 12468)):
#0  0x00007f6f9a463cdd in get_nprocs () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007f6f9a3f1bca in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x00007f6f9a3f5b79 in malloc () from /lib/x86_64-linux-gnu/libc.so.6
#3  0x00007f6f9a3e1c9b in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#4  0x00007f6f9a94caa3 in ?? () from /lib/x86_64-linux-gnu/libnss_compat.so.2
#5  0x00007f6f9a94dba6 in _nss_compat_setpwent () from /lib/x86_64-linux-gnu/libnss_compat.so.2
#6  0x000000000055818b in __nss_setent ()
#7  0x000000000054d523 in setpwent ()
#8  0x00000000004189ce in completer_t::try_complete_user (this=0x7f6f99432a00, str=...) at complete.cpp:1637
#9  0x000000000041e2ac in complete (cmd=..., comps=..., type=<optimized out>, commands_to_load=0x23df7d0) at complete.cpp:1723
#10 0x0000000000457fff in autosuggestion_context_t::threaded_autosuggest (this=0x23df6c0) at reader.cpp:1294
#11 0x0000000000451ea9 in threaded_autosuggest (ctx=<optimized out>) at reader.cpp:1307
#12 0x0000000000481d89 in iothread_worker (threadPtr=0x828550) at iothread.cpp:110
#13 0x000000000048db5a in start_thread (arg=0x7f6f99433700) at pthread_create.c:308
#14 0x00000000005557d9 in clone ()
#15 0x0000000000000000 in ?? ()

[ridiculousfish]

Googling shows a similar crash in tcsh http://mx.gw.com/pipermail/tcsh/2010-August/004169.html
and one in bash at http://web.archiveorange.com/archive/v/wmeLDmw82cp6N2SwY1bf

Amusingly both seem to be related to completions.

Since these processes aren't multithreaded I think we can rule out threading issues and conclude that it's a bug in libnsl. The next step would be to identify it and see if we can work around it.

[etu]

Just for reference, it does not crash on my hardened 64-bit no-multilib gentoo-system with pax and grsec enabled in kernel...

[ridiculousfish]

I haven't been able to reproduce this (tried Fedora 17 64 bit), and I haven't been able to find a way to enumerate users aside from opening /etc/passwd directly (yuck).

If anyone has any suggestions, please share; for now I'm pushing out of 2.0 release.

[faho]

Can anyone still reproduce this?

[ridiculousfish]

Ancient history, let's close.