hisham hm

Crash-course sobre gdb: decifrando segmentation faults

Como não ficar no escuro em caso de segmentation fault:

1) Compile o programa com símbolos de depuração

Use a flag “-g” do gcc para compilar o programa com símbolos de depuração. Certifique-se que todos os objetos estão compilados com “-g”. Você pode precisar dar “make clean”.

2) Seu ambiente deve estar com “core dump” habilitado

Ao ocorrer um “segmentation fault”, o Linux pode gerar um arquivo que é imagem da memória do programa na hora que ele “deu pau”, o chamado “core dump” (curiosidade: o “core dump” tem esse nome por causa da memória de ferrite dos anos 1950-1970, que era chamada de “magnetic-core memory“, ou simplesmente “core”). Com o arquivo de “core dump”, podemos fazer a análise post-mortem do processo e descobrir por que ele explodiu.

Digite “ulimit -c” no seu shell. Se ele retornar “0”, o sistema não irá gerar os arquivos “core”. Digite “ulimit -c unlimited” para remover a restrição de tamanho aos arquivos core. Esta é uma configuração por processo, que é herdada pelos processos filhos (portanto, só vale no terminal onde foi digitada). Para torná-la “permanente”, você pode configurar isso no seu .bash_profile, .zshrc ou equivalente.

3) Rodando o gdb

Com o binário e o core dump na mão, rode o gdb:

gdb ./meu_programa_bugado core

(Dependendo da distro, o arquivo core pode ter o número do processo no seu nome, como “core.1234”)

4) Comandos básicos do gdb

Com esses comandos básicos, podemos analisar os dados de um core dump:

Há muito mais que se pode aprender sobre o gdb — é um debugger completo capaz de depurar o programa enquanto roda (gdb -p pid), lidar com threads, etc… mas esse conjunto pequeno de comandos apresentado aqui já é uma mão na roda para decifrar os “segmentation faults”!


Add comment

Fill out the form below to add your own comments.

CAPTCHA imageReload imageAudible version of CAPTCHA-image