Я хотел бы узнать, где именно работает приложение, написанное на C/C++. Я не могу отлаживать приложение напрямую, ни с помощью gdb/lldb, ни с помощью среды IDE, потому что приложение запускается программой (это контроллер робота для программного обеспечения для моделирования роботов в Интернете). В консоли OSX я могу найти «Отчет о диагностике пользователя», который даже показывает трассировку соломы в момент сбоя. мне просто нужно выяснить, где именно в моем исходном коде аварии происходит, но я не понимаю, следующий синтаксис трассировки стека:reverse engineer OSX User Diagnostic Report trace trace
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 строк, а контроллер не скомпилирован с информацией об отладке.
Я бы сказал, что '+ 4839' говорит, что он назвал' strtol_l' в инструкции 4839-го процессора после того, как он ввел 'main'. Если вы разобрали двоичный файл, который вы запустили, вы сможете найти, какая инструкция есть и, возможно, найти ссылку на знакомую строку кода в окружающей сборке. – nonsensickle
Это байтовый счет, смещение от начала 'main'. – user3386109
, если вы перекомпилируете код контроллера с помощью «-ggdb» (который сделает исполняемый файл значительно большим), а затем пусть он запустится до тех пор, пока он не будет неисправен, тогда трассировка стека будет содержать номера строк и т. Д. И т. Д. – user3629249