установка gdb выходит из точки останова, не работающей?
Если Вы имеете время, выполняете взломщика пароля против него.
3 ответа
Есть две общие причины, по которым точка останова _exit "пропущена" - либо GDB не установил точку останова в нужном месте, либо программа выполняет (моральный эквивалент) системного вызова (SYS_exit, ...)
Что info break и дизассемблируют _exit говорят?
удалось убедить GDB правильно установить точку останова с помощью break * & _ exit . В качестве альтернативы GDB-7.0 поддерживает системный вызов catch . Что-то вроде этого должно работать (при условии Linux / x86_64 ; обратите внимание, что на ix86 числа будут другими) независимо от того, как программа выходит:
(gdb) catch syscall 60
Catchpoint 3 (syscall 'exit' [60])
(gdb) catch syscall 231
Catchpoint 4 (syscall 'exit_group' [231])
(gdb) c
Catchpoint 4 (call to syscall 'exit_group'), 0x00007ffff7912f3d in _exit () from /lib/libc.so.6
Обновление:
Ваш комментарий указывает, что точка останова _exit установлена правильно, поэтому вполне вероятно, что ваш процесс просто не выполняет _exit .
Остается системный вызов (SYS_exit, ...) и один другая возможность (которую я упустил раньше): все потоки выполняют pthread_exit . Вы также можете установить точку останова на pthread_exit (и выполнять информационный поток каждый раз, когда вы нажимаете на него - последний поток, выполняющий pthread_exit , вызовет процесс для завершения).
Edit:
Также стоит отметить, что вы можете использовать мнемонические имена, а не номера системных вызовов. Вы также можете одновременно добавить несколько системных вызовов в список перехвата следующим образом:
(gdb) catch syscall exit exit_group
Catchpoint 2 (syscalls 'exit' [1] 'exit_group' [252])
Установка точки останова на _exit была хорошей идеей.
Вы также можете попробовать выполнить статическую линковку, просто чтобы убрать из таблицы ряд потенциальных проблем с GDB.
0177 подозрительно похож на статус ожидания wait (2) возвращается для дочерний остановлен , но gdb выводит статус выхода , что другое дело, так что, вероятно, реальный аргумент выхода.
Возможно, у вас есть несколько ленивых ссылок, не решенных в какой-нибудь общей библиотеке, загруженной в процесс. У меня точно такая же ситуация, когда "кто-то где-то" вышел из процесса и оказалось, что это неразрешенная ссылка.
Проверьте свой процесс с помощью опции "ldd -r".
Похоже на ld.so или что-то вроде того, что делает ленивое преобразование некоторых символов в единую функцию выхода (которая должна быть прервана IMHO).
Моя ситуация:
$ ldd ./program
undefined symbol: XXXX (/usr/lib/libYYY.so)
$./program
program: started!
...
<program is running regardless of undefined references>
Теперь выход появился, когда я вызвал некий сценарий, который использовал функцию, которая была неопределена. Она всегда выходила с exitcode=127 и gdb сообщил 0177.