Re: Depurar procurando segfault
Em Fri, 13 May 2005 15:54:59 -0300 Thadeu Penna <tjpp@if.uff.br> disse
que:
O gnucash voltou a funcionar, "sozinho" :-) (atualização de ontem)
> O problema maior é este: os programas não são compilados com opções de
> debug por questões de performance. Na maioria das vezes rodar o strace
> pode ser mais esclarecedor (não adianta muito se o programa faz uso
de
> threads)
O strace deu a seguinte mensagem:
===========================================================================
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or
directory)
open("/lib/tls/libtk8.4.so.0", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/lib/libtk8.4.so.0", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/usr/lib/tls/libtk8.4.so.0", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/usr/lib/i686/cmov/libtk8.4.so.0", O_RDONLY) = -1 ENOENT (No such file
or directory)
open("/usr/lib/i686/libtk8.4.so.0", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/usr/lib/libtk8.4.so.0", O_RDONLY) = 5
read(5, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\240^\1"..., 512)
= 512
fstat64(5, {st_mode=S_IFREG|0644, st_size=886224, ...}) = 0
old_mmap(NULL, 892340, PROT_READ|PROT_EXEC, MAP_PRIVATE, 5, 0) = 0xb6fa1000
old_mmap(0xb706e000, 53248, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 5,
0xcc000) = 0xb706e000
close(5) = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
Aparentemente ele estava procurando a libtk8.4, a achou e quando começou a
ler, fechou e caiu.
O gdb não ajudou muito mais, tampouco:
========================================================================
bt em "gdb gaim" depois do segfault
#0 0xb7faf405 in _dl_relocate_object () from /lib/ld-linux.so.2
#1 0xb7890613 in _dl_open () from /lib/tls/libc.so.6
#2 0xb7fb2016 in _dl_catch_error () from /lib/ld-linux.so.2
#3 0xb788fed6 in _dl_open () from /lib/tls/libc.so.6
#4 0xb7a43038 in dlopen () from /lib/tls/libdl.so.2
#5 0xb7fb2016 in _dl_catch_error () from /lib/ld-linux.so.2
#6 0xb7a434a6 in dlerror () from /lib/tls/libdl.so.2n
#7 0xb7a42fe4 in dlopen () from /lib/tls/libdl.so.2
#8 0xb7a4613f in ?? () from /usr/lib/libgmodule-2.0.so.0
#9 0x081d6408 in ?? ()
#10 0x00000102 in ?? ()
#11 0x00000000 in ?? ()
#12 0xb7a48540 in ?? () from /usr/lib/libgmodule-2.0.so.0
#13 0xb7a48540 in ?? () from /usr/lib/libgmodule-2.0.so.0
#14 0x081d6408 in ?? ()
#15 0xbfeb46d8 in ?? ()
#16 0xb7a468f0 in g_module_open () from /usr/lib/libgmodule-2.0.so.0
#17 0xb7a468f0 in g_module_open () from /usr/lib/libgmodule-2.0.so.0
#18 0x08080678 in gaim_plugin_probe ()
#19 0x0808188f in gaim_plugins_probe ()
#20 0x080f8688 in main ()
O único suspeito (dado que todo o resto do sistema está ok) é o libgmodule-2.0,
que está lá.
Alguma luz?
Abraço
Cláudio
Reply to: