обратный инжиниринг трассировки стека отчетов диагностики пользователей 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 строк, и контроллер не скомпилирован с отладочной информацией.

2

Решение

Вы можете отлаживать процесс контроллера робота в gdb с помощью команды gdb attach с PID процесса контроллера робота, который вы хотите отладить. Это позволит gdb присоединять процесс на лету и отлаживать его, как если бы он был первоначально запущен из gdb. Это хорошо объяснено в документации Webots здесь: http://www.cyberbotics.com/dvd/common/doc/webots/guide/section5.5.html

1

Другие решения