Arch Linux

ArchArael

Member

Registered: 2005-06-14

Posts: 504

debuging a fish bug; suggestions are welcome

Hi guys,

I have this problem with fish shell. http://bugs.archlinux.org/task/17452?project=5

This is the output from gdb's bt command reading the fish core .

(gdb) core core 
Core was generated by `fish'.
Program terminated with signal 11, Segmentation fault.
#0  0xb771ceb8 in ?? ()
(gdb) bt
#0  0xb771ceb8 in ?? ()

Do you have any suggestion about how could I proceed in debugging further? Any other suggestion?

EDIT: A colleague of mine suggested me that the problem is that debugging messages are not enabled so ?? is displayed instead of the function name. I'll try to recompile with debugging messages enabled.

Last edited by ArchArael (2009-12-18 09:13:06)

Grazz256

Member

Registered: 2009-06-28

Posts: 69

Re: debuging a fish bug; suggestions are welcome

Assuming your compiling with gcc use the -g option for the compiler and linker, that will give you full debug info.
You may also want to disable and optimization as I think it can make debugging more difficult.

Cheers,
Jon Estey

ArchArael

Member

Registered: 2005-06-14

Posts: 504

Re: debuging a fish bug; suggestions are welcome

Assuming your compiling with gcc use the -g option for the compiler and linker, that will give you full debug info.
You may also want to disable and optimization as I think it can make debugging more difficult.

Cheers,
Jon Estey

Thank you very much. I'll try.

ArchArael

Member

Registered: 2005-06-14

Posts: 504

Re: debuging a fish bug; suggestions are welcome

I compiled the code with -g option, then I started the debugging session.

I found how to replicate the crash. Basically it seem to be related with the focus. What I do to obtain the crash is:

1. killall fishd
2. gdb ./fish # my -g fish binary
3. run  >> in gdb shell
4. start several (from 5 to 10) terminal emulators running fish and switch between them, you will notice than sometimes the focus is gained only after you press a key: For example ls will end up in just s on the prompt.
5. after some time fishd crashes. You will notice that the terminal emulators will start to disappear as soon as they get the focus.

Here is the gdb backtrace:

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff78b3dc8 in wcscmp () from /lib/libc.so.6
(gdb) backtrace
#0  0x00007ffff78b3dc8 in wcscmp () from /lib/libc.so.6
#1  0x000000000042a377 in input_function_get_code (
    name=0x1 <Address 0x1 out of bounds>) at input.c:880
#2  0x000000000042a6d0 in input_try_mapping () at input.c:439
#3  input_readch () at input.c:499
#4  0x0000000000425090 in reader_readline () at reader.c:2587
#5  0x0000000000426aba in read_i (fd=6876720, io=0x0) at reader.c:2463
#6  reader_read (fd=6876720, io=0x0) at reader.c:3329
#7  0x000000000043a80e in main (argc=1, argv=0x7fffffffe778) at fish.c:326

Here is the valgrind backtrace:

 ==433== Invalid read of size 8
==433==    at 0x42A6C4: input_readch (input.c:439)
==433==    by 0x42508F: reader_readline (reader.c:2587)
==433==    by 0x426AB9: reader_read (reader.c:2463)
==433==    by 0x43A80D: main (fish.c:326)
==433==  Address 0x55fa2a8 is 8 bytes inside a block of size 16 free'd
==433==    at 0x4C23A18: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==433==    by 0x42A557: input_mapping_erase (input.c:565)
==433==    by 0x40C0EC: builtin_bind (builtin.c:564)
==433==    by 0x4105A1: builtin_run (builtin.c:3837)
==433==    by 0x417119: exec (exec.c:1376)
==433==    by 0x420BE5: eval (parser.c:2376)
==433==    by 0x4168CA: T.90 (exec.c:802)
==433==    by 0x416FB7: exec (exec.c:1227)
==433==    by 0x420BE5: eval (parser.c:2376)
==433==    by 0x4168CA: T.90 (exec.c:802)
==433==    by 0x416FB7: exec (exec.c:1227)
==433==    by 0x420BE5: eval (parser.c:2376)
==433== 
==433== Invalid read of size 8
==433==    at 0x42A6E1: input_readch (input.c:445)
==433==    by 0x42508F: reader_readline (reader.c:2587)
==433==    by 0x426AB9: reader_read (reader.c:2463)
==433==    by 0x43A80D: main (fish.c:326)
==433==  Address 0x55fa2a0 is 0 bytes inside a block of size 16 free'd
==433==    at 0x4C23A18: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==433==    by 0x42A557: input_mapping_erase (input.c:565)
==433==    by 0x40C0EC: builtin_bind (builtin.c:564)
==433==    by 0x4105A1: builtin_run (builtin.c:3837)
==433==    by 0x417119: exec (exec.c:1376)
==433==    by 0x420BE5: eval (parser.c:2376)
==433==    by 0x4168CA: T.90 (exec.c:802)
==433==    by 0x416FB7: exec (exec.c:1227)
==433==    by 0x420BE5: eval (parser.c:2376)
==433==    by 0x4168CA: T.90 (exec.c:802)
==433==    by 0x416FB7: exec (exec.c:1227)
==433==    by 0x420BE5: eval (parser.c:2376)
==433== 
==433== Invalid read of size 8
==433==    at 0x42A5A1: input_exec_binding (input.c:379)
==433==    by 0x42A7AF: input_readch (input.c:454)
==433==    by 0x42508F: reader_readline (reader.c:2587)
==433==    by 0x426AB9: reader_read (reader.c:2463)
==433==    by 0x43A80D: main (fish.c:326)
==433==  Address 0x55fa2a8 is 8 bytes inside a block of size 16 free'd
==433==    at 0x4C23A18: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==433==    by 0x42A557: input_mapping_erase (input.c:565)
==433==    by 0x40C0EC: builtin_bind (builtin.c:564)
==433==    by 0x4105A1: builtin_run (builtin.c:3837)
==433==    by 0x417119: exec (exec.c:1376)
==433==    by 0x420BE5: eval (parser.c:2376)
==433==    by 0x4168CA: T.90 (exec.c:802)
==433==    by 0x416FB7: exec (exec.c:1227)
==433==    by 0x420BE5: eval (parser.c:2376)
==433==    by 0x4168CA: T.90 (exec.c:802)
==433==    by 0x416FB7: exec (exec.c:1227)
==433==    by 0x420BE5: eval (parser.c:2376)
==433== 
==433== Invalid read of size 8
==433==    at 0x42A78A: input_readch (input.c:500)
==433==    by 0x42508F: reader_readline (reader.c:2587)
==433==    by 0x426AB9: reader_read (reader.c:2463)
==433==    by 0x43A80D: main (fish.c:326)
==433==  Address 0x55fa2a0 is 0 bytes inside a block of size 16 free'd
==433==    at 0x4C23A18: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==433==    by 0x42A557: input_mapping_erase (input.c:565)
==433==    by 0x40C0EC: builtin_bind (builtin.c:564)
==433==    by 0x4105A1: builtin_run (builtin.c:3837)
==433==    by 0x417119: exec (exec.c:1376)
==433==    by 0x420BE5: eval (parser.c:2376)
==433==    by 0x4168CA: T.90 (exec.c:802)
==433==    by 0x416FB7: exec (exec.c:1227)
==433==    by 0x420BE5: eval (parser.c:2376)
==433==    by 0x4168CA: T.90 (exec.c:802)
==433==    by 0x416FB7: exec (exec.c:1227)
==433==    by 0x420BE5: eval (parser.c:2376)
==433== 
==433== Invalid read of size 8
==433==    at 0x42A5A1: input_exec_binding (input.c:379)
==433==    by 0x42A7F7: input_readch (input.c:524)
==433==    by 0x42508F: reader_readline (reader.c:2587)
==433==    by 0x426AB9: reader_read (reader.c:2463)
==433==    by 0x43A80D: main (fish.c:326)
==433==  Address 0x55fa2a8 is 8 bytes inside a block of size 16 free'd
==433==    at 0x4C23A18: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==433==    by 0x42A557: input_mapping_erase (input.c:565)
==433==    by 0x40C0EC: builtin_bind (builtin.c:564)
==433==    by 0x4105A1: builtin_run (builtin.c:3837)
==433==    by 0x417119: exec (exec.c:1376)
==433==    by 0x420BE5: eval (parser.c:2376)
==433==    by 0x4168CA: T.90 (exec.c:802)
==433==    by 0x416FB7: exec (exec.c:1227)
==433==    by 0x420BE5: eval (parser.c:2376)
==433==    by 0x4168CA: T.90 (exec.c:802)
==433==    by 0x416FB7: exec (exec.c:1227)
==433==    by 0x420BE5: eval (parser.c:2376)
==433==

I'm not expert in debugging with gdb and valgrind. I'm still learning how to do it so if you have suggestions please post. As soon as possible I will post this in the fish-users mail list. I don't hope I will receive any answer soon that's why I'm trying to fix this thing myself.

sr

Member

Registered: 2009-10-12

Posts: 51

Re: debuging a fish bug; suggestions are welcome

==433== Invalid read of size 8
==433==    at 0x42A6E1: input_readch (input.c:445)
==433==    by 0x42508F: reader_readline (reader.c:2587)
==433==    by 0x426AB9: reader_read (reader.c:2463)
==433==    by 0x43A80D: main (fish.c:326)
==433==  Address 0x55fa2a0 is 0 bytes inside a block of size 16 free'd
==433==    at 0x4C23A18: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==433==    by 0x42A557: input_mapping_erase (input.c:565)

Apologies if you know this already, but what this says is that input_readch() is trying to read some data from an array that's already been freed by input_mapping_erase(). Is that expected? valgrind is sometimes a bit confused about memory problems, but this seems to be a fairly clear case of using heap memory after it's been freed.

ArchArael

Member

Registered: 2005-06-14

Posts: 504

Re: debuging a fish bug; suggestions are welcome

==433== Invalid read of size 8
==433==    at 0x42A6E1: input_readch (input.c:445)
==433==    by 0x42508F: reader_readline (reader.c:2587)
==433==    by 0x426AB9: reader_read (reader.c:2463)
==433==    by 0x43A80D: main (fish.c:326)
==433==  Address 0x55fa2a0 is 0 bytes inside a block of size 16 free'd
==433==    at 0x4C23A18: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==433==    by 0x42A557: input_mapping_erase (input.c:565)

Apologies if you know this already, but what this says is that input_readch() is trying to read some data from an array that's already been freed by input_mapping_erase(). Is that expected? valgrind is sometimes a bit confused about memory problems, but this seems to be a fairly clear case of using heap memory after it's been freed.

Thank you for your suggestion. This problem was probably due to my key binding configuration. It's strange but by overriding the key binding function this way:

function keybindings -d "User keybindings"
    bind \eu 'cd .. ; commandline -f repaint'
    bind \e\. history-token-search-backward
    bind \eg __fish_grep
    bind \eh 'commandline -aj "~/"; commandline -f end-of-line'
    bind \es 'commandline -aj "/etc/rc.d/"; commandline -f end-of-line'
    bind \ej prevd-or-backward-word
    bind \ek nextd-or-forward-word
    fish_default_key_bindings # all other fish key bindings
end

It ended up with crashes after switching between terminal emulators. I solved this by copying in my .config/fish/functions folder the function /usr/share/fish/functions/fish_default_key_bindings.fish and by adding my key bindings configurations to it. This way only one and not two functions are called for key binding configuration. It seems stable right now but I'm suspecting that this was not the same bug as the previous one. I hope it is though. Anyway, after modifying this function I didn't had any crash so far. I don't know yet it the problem was this one or not. I'll let you know if I discover. Meanwhile I'm enjoying this apparent stability.

Last edited by ArchArael (2009-12-30 05:57:00)