обратный инжиниринг трассировки стека отчетов диагностики пользователей OSX
Я хотел бы узнать, где именно происходит сбой приложения, написанного на C / C ++. Я не могу отладить приложение напрямую, ни используя gdb / lldb, ни используя IDE, потому что приложение запускается программой (это контроллер робота для программного обеспечения для моделирования роботов webots). В консоли OSX я могу найти «Диагностический отчет пользователя», который даже показывает следы потертостей в момент сбоя.
Мне просто нужно выяснить, где именно в моем исходном коде происходит сбой, но я не понимаю следующий синтаксис трассировки стека:
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: EXC_I386_GPFLT
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libsystem_c.dylib 0x00007fff92d6b859 strtol_l + 77
1 controller_2 0x0000000100006b57 main + 4839
2 controller_2 0x00000001000010b4 start + 52
Видимо где-то (+4839) в моем int main() {} функция что-то в конце концов вызывает strtol_l (должен быть косвенным, потому что в коде контроллера нет вызова этой функции), что вызывает сбой.
Что это + 4839 стоять за? это смещение блока памяти? Это не может быть номер строки исходного кода, так как исходный код для контроллера составляет ~ 1200 строк, и контроллер не скомпилирован с отладочной информацией.
Решение
Вы можете отлаживать процесс контроллера робота в gdb с помощью команды gdb attach с PID процесса контроллера робота, который вы хотите отладить. Это позволит gdb присоединять процесс на лету и отлаживать его, как если бы он был первоначально запущен из gdb. Это хорошо объяснено в документации Webots здесь: http://www.cyberbotics.com/dvd/common/doc/webots/guide/section5.5.html
Другие решения