Bus error (core dumped)

Antes de mais nada, o que é um “Segmentation fault (core dumped)” e um “Bus error (code dumped)”?

Esta foi a primeira pergunta me que fiz, não foi muito fácil achar a resposta, mas achei:

Segmentation Fault: O programa está tentando acessar uma área da memória que não lhe pertence e o erro foi detectado pelo sistema operacional.

Bus Error: O programa está tentando acessar uma área da memória que não lhe pertence e o erro foi detectado pela CPU.

Agora posso continuar, então vamos ao que interessa:

Estou recebendo “Bus error” quando tento rodar o ghostscript (gs), eu descobri isso porque o Latex não estava gerando os arquivos pdf com as imagens postscript incluídas no texto.

Após tentar abrí-las no evince e outros visualizados sem sucesso suspeitei que o problema fosse nas libs do ghostscript, não deu outra.

# strace /usr/bin/gs

open(“/usr/lib/libgs.so.8”, O_RDONLY) = 3
read(3, “\177ELF\2\1\1\3>\1\240\27\16″…, 832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=5971968, …}) = 0
mmap(NULL, 12024472, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x2b073d2b9000
mprotect(0x2b073d77b000, 2097152, PROT_NONE) = 0
mmap(0x2b073d97b000, 3284992, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x4c2000) = 0x2b073d97b000
— SIGBUS (Bus error) @ 0 (0) —
+++ killed by SIGBUS (core dumped) +++
Process 6842 detached

Ao que parece o erro está ocorrendo após o gs alocar memória, vamos verificar se a memória virtual está limitada:

# ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 15864
max locked memory (kbytes, -l) 32
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 15864
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited

Este não é o problema, mas como podemos ver a geração do arquivo de core dump (core), está desativada, vamos ativar:
# ulimit -c 1024

Agora quando tentar rodar o programa ele irá gerar um arquivo chamado core que contém os estado que o aplicativo estava no momento que o core dump ocorreu.

Então resolvi tentar depurar o ghostscript juntamente com o arquivo de core dump gerado:

root@tux:~# gdb /usr/bin/gs core
GNU gdb 6.6-debian
Copyright (C) 2006 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 “show copying” to see the conditions.
There is absolutely no warranty for GDB. Type “show warranty” for details.
This GDB was configured as “x86_64-linux-gnu”…
(no debugging symbols found)
Using host libthread_db library “/lib/libthread_db.so.1”.
(gdb) run
Starting program: /usr/bin/gs
(no debugging symbols found)

Program received signal SIGBUS, Bus error.
0x00002b351b8d8fa0 in ?? () from /lib64/ld-linux-x86-64.so.2
(gdb)

O gs não foi compilado com a flag de debug ativada (-g), porém podemos ver que o erro ocorre na biblioteca ld-linux-x86-64.so.2.

Eu sei que a ld-linux-x86-64.so.2 pertence ao pacote libc6-amd64, então isto me fez lembrar que o problema comecou a ocorrer quando eu fiz a atualizacao do sistema. Um dpkg -l “libc6*” me mostrou que a libc6 instalada era a versao 2.6.1-1ubuntu10.

Solucao:
dpkg -i –force-overwrite libc6_2.6.1-1ubuntu9_amd64.deb

Mais uma vez fica a impressão (ou certeza) que a Canonical não testa corretamente as atualizações antes de disponibiliza-las para o público. Isto é muito grave, pois as pessoas perderão a confiança no Ubuntu.

BUG:
https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/161772

3 thoughts on “Bus error (core dumped)

  1. Prova disso foi o meu som que não funciona mais. Ando desanimado mesmo com esta versão. Que tal colocar o meu som no ar de novo ? Não sei nem onde começar, definitivamente não entendo nada de desktop e afins. E não quero entender … isto deveria funcionar e pronto.

  2. Pois é, eu também queria um final feliz, de preferência descobrindo exatamente onde o problema estava. Eu consegui isolá-lo, mas não consegui descobrir qual era realmente o problema.

    Para conseguir resolver, o pacote libc6 deveria ter sido compilado com os símbolos de debug. Também não sei se meu conhecimento de gdb seria suficiente para encontrar o erro. Só sei usar o básico do gdb como breakpoints, instruções linha a linha (next), instruções linha a linha entrando dentro das funções (step), nada muito além.

    O próximo BUG eu irei até o fim, quero aprender mais como depurar e descobrir erros com o gdb.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s