Skip to content

Commit a4d9bc0

Browse files
committed
Added core dumps example
1 parent 32bc6ac commit a4d9bc0

4 files changed

Lines changed: 87 additions & 1 deletion

File tree

README.md

Lines changed: 4 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1 +1,4 @@
1-
# debug_examples
1+
# Debug examples
2+
3+
## Debugging with core dumps
4+
`core-dumps-example` contains simple example of generating and using core dumps for debugging.

core-dump-example/Makefile

Lines changed: 10 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,10 @@
1+
PROG_NAME=program
2+
3+
.PHONY=all clean
4+
5+
all:
6+
gcc -g main.c -o ${PROG_NAME}
7+
8+
clean:
9+
rm -rf ./*.o
10+

core-dump-example/README.md

Lines changed: 55 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,55 @@
1+
# Core dump example
2+
3+
Пример программы с ошибкой, приводящей к аварийному завершению программы для демонстрации использования дампов памяти при отладке программы.
4+
5+
## Сборка программы
6+
Собрать программу можно с помощью make и компилятора gcc (предварительно убедитесь в их наличии):
7+
```
8+
make
9+
```
10+
11+
## Настройка окружения для записи дампов памяти в текущую директорию
12+
```
13+
sudo sysctl -w kernel.core_pattern=$(pwd)/core-%e.%p.%t
14+
ulimit -c unlimited
15+
```
16+
17+
## Запуск программы и отладка
18+
Запус к программы:
19+
```
20+
./program
21+
```
22+
23+
Результат: `Ошибка сегментирования (образ памяти сброшен на диск)`. В выводе видно, что произошла запись на диск и в текущей директории появился файл `core-*`.
24+
25+
Теперь мы можем запустить отладкич gdb и восставновить состояние программы на момент завершения работы:
26+
```
27+
gdb ./program <core>
28+
```
29+
30+
Вместо `<core>` необходимо указать имя сгенерированного файла дампа памяти.
31+
32+
После запуска отладчика получим:
33+
```
34+
Core was generated by `./program'.
35+
Program terminated with signal SIGSEGV, Segmentation fault.
36+
#0 0x0000605ab889d139 in faulty_function (user=0x0) at main.c:9
37+
9 user->id = 100;
38+
```
39+
Благодаря отладочным символам мы видим ошибку в строке 9 файла `main.c`. Ошибка в функции `faulty_function`, где видим, что аргумент `user=0x0`. Место ошибки становится очевидным.
40+
41+
Чтобы легче было понять из какой функции и при каких обстоятельствах была вызвана функция, можно получить стек вызовов:
42+
```
43+
(gdb) bt
44+
#0 0x0000605ab889d139 in faulty_function (user=0x0) at main.c:9
45+
#1 0x0000605ab889d162 in main () at main.c:15
46+
(gdb) up
47+
#1 0x0000605ab889d162 in main () at main.c:15
48+
15 faulty_function(user);
49+
(gdb) info locals
50+
user = 0x0
51+
```
52+
53+
В отладчике мы получили стек вызовов с помощью команды `bt`, поднялись по этому стеку наверх к функции #1 (`main`) с помощью `up` и вывели информацию о локальных переменных. Оказалось, что уже в функции `main`, переменная `user` была нулем.
54+
Зачастую в программе сложнее понять из-за чего переменная получает значение нуля, поэтому информация о локальных переменных в функциях стека вызовов может сильно упростить понимание аварийной ситуации.
55+

core-dump-example/main.c

Lines changed: 18 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,18 @@
1+
#include <stdlib.h>
2+
3+
typedef struct {
4+
int id;
5+
char name[32];
6+
} User;
7+
8+
void faulty_function(User* user) {
9+
user->id = 100;
10+
}
11+
12+
int main() {
13+
User* user = NULL;
14+
15+
faulty_function(user);
16+
17+
return 0;
18+
}

0 commit comments

Comments
 (0)