LINUX.ORG.RU

Проблема в GDB - пустой стэк.


0

0

Сервер отлаживался под GDB 5.3. Когда сервер получил SIGSEGV GDB остановил выполнение сервера и с радостью мне сообщил, что по адресу 0x0 в функции ?? () возникла ошибка сегментации. На команду 'bt' GDB выдал пустой стэк. Обращался к разработчикам GDB с подробным описанием ошибки, указал им версию компилятора (gcc version egcs-2.91.66) и GDB, как они и просили, но они на отрез отказались помогать, требуя typescript файл и обвиняя, таким образом, меня, лживую морду, в фальсификации информации. =)))

Один программер из баг-рассылки подкинул интересную идею. Вот его письмо:

"I strongly suspect that this is caused by a zero function pointer call, and the example below indeed shows a regression with backtracing from zero function pointer calls between gdb-5.3 and gdb-6.0.

I am not familiar enough with the new frame code to propose a fix though, sorry.

pes@xxxx_7$ cat zerofun.c
void x()
{
void (*fp)() = 0;
fp();
}
int
main()
{
x();
return 0;
}
pes@xxxx_8$ gcc -g zerofun.c
pes@xxxx_9$ gdb-5.3 a.out
GNU gdb 5.3
Copyright 2002 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 "i686-pc-linux-gnu"...
(gdb) r
Starting program: ..../a.out

Program received signal SIGSEGV, Segmentation fault.
0x00000000 in ?? ()
(gdb) bt
#0 0x00000000 in ?? ()
#1 0x08048306 in x () at zerofun.c:4
#2 0x0804831d in main () at zerofun.c:9
#3 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6
(gdb) q
The program is running. Exit anyway? (y or n) y
pes@xxxx_10$ gdb-6.0 a.out
GNU gdb 6.0
Copyright 2003 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 "i686-pc-linux-gnu"...
(gdb) r
Starting program: ..../a.out

Program received signal SIGSEGV, Segmentation fault.
0x00000000 in ?? ()
(gdb) bt
#0 0x00000000 in ?? ()
(gdb) q
The program is running. Exit anyway? (y or n) y"

В кратце, проблема заключается в вызове функции по нулевому указателю. В сервере как раз есть динамически подключаемая бибилотека. Очень вероятно, что ошибка идет из серверной функции, возвращающей адреса требуемых функций из динамической библиотеки.

Но проблема возникла как раз в 5.3, а не в 6.0.

Кто что думает по этому поводу. Когда ошибка возникнет в следующий раз, я опять не получу никакой информации. А это грозит отправкой большого булыжника в мой огород скоростным рейсом.

Спасибо.


Честно говоря, не сталкивался с таким в gdb (сейчас проверю пример).

А как в этом случае работает libc backtrace?
Типа
export LD_PRELOAD=/lib/libSegFault.so
./a.out

Murr ★★
()
Ответ на: комментарий от Murr

Мдя Действительно с gdb 6.0 глюк :( Так что или ручками раскручивайте стек фрейм по ebp - или ... стоит забить на 6.0.

Murr ★★
()
Ответ на: комментарий от Murr

Re

У меня очень часто была такая фигня, когда съезжал стек из-за разных calling convensions... Посмотри, если это можно сделать, точно ли _все_ используемые модули скомпилированы gcc. Если есть сырцы на ассемблере, очень рекомендуется проверить в этих модулях в используемых функциях баланс стека. Вот, ну и еще можно попробовать установить обработчик сигнала SIGSEGV с SA_SIGINFO и там распечатать контекст (который будет третьим аргументом в этом обработчике). В частности, наибольший интерес представляет eip.

Debugger
()
Ответ на: Re от Debugger

Re

Блин, что-то у меня с головой.... Не надо ловить SIGSEGV :) Регистры можно посмотреть в gdb.....

Debugger
()
Ответ на: Re от Debugger

Re

Ну так что можно узнать EIP, затем узнать, какому модулю принадлежит этот адрес, получить дамп этой библиотеки, ну и вычислеть адрес в ее сегменте .text, где произошел crash....

Debugger
()

Не клевещите на 6.0.

Косвенный вызов нуля -- причина достойная, но не единственная. Такие же симптомы может иметь переполнение буфера и тому подобная порча стека. Как ловить это ловить -- не знаю. Первое, что приходит в голову -- прицепить (soft) ICE, включить надлежащий трггер и копаться в трассировке...

vnp
()
Ответ на: Re от Debugger

1. Этот примерчик я и сам пробовал. У меня в 5.3 с этим все впорядке. Стэк раскручивается. Но при падении моего сервака все обстаяло не так. Стэк был пуст.

2. А что мне даст eip? Он же нулевой в таком случае.

Lestat
() автор топика
Ответ на: комментарий от Lestat

Изучил тему с динамической библиотекой. Функция которая возвращает адреса функций из библиотеки везде принимает конкретные значения. Эти значения имена существующих функций. Я проверил. И даже если бы dlsym вернула нулевой указатель, то появилась бы запись в логах. Логи я просмотрел, такой записи нет.

Ассемблерные вставки, это только команд, типа, "asm volatile ("eieio":::memory)" и т.п. Меняется только аргумент. В ассемблере я если честно не силен, т.ч. ничего сказать не могу. Но сомневаюсь, что это связано со стэком, тем более его балансом.

Какие еще идеи?

Lestat
() автор топика
Ответ на: комментарий от Lestat

GDB'шники начали работать над багом: http://sources.redhat.com/ml/gdb-prs/2003-q4/msg00223.html. Про меня сказали: "reporter isn't particular helpful". =)) Ну-ну. Им только typescript подавай. Остальное они за помощь не считают. Неблагодарные. =/

Lestat
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.