2015-05-29 3 views
2

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

+0

Я бы сказал, что '+ 4839' говорит, что он назвал' strtol_l' в инструкции 4839-го процессора после того, как он ввел 'main'. Если вы разобрали двоичный файл, который вы запустили, вы сможете найти, какая инструкция есть и, возможно, найти ссылку на знакомую строку кода в окружающей сборке. – nonsensickle

+1

Это байтовый счет, смещение от начала 'main'. – user3386109

+0

, если вы перекомпилируете код контроллера с помощью «-ggdb» (который сделает исполняемый файл значительно большим), а затем пусть он запустится до тех пор, пока он не будет неисправен, тогда трассировка стека будет содержать номера строк и т. Д. И т. Д. – user3629249

ответ

1

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

+0

Хорошо, ну да, вы действительно можете, но в моем случае это довольно сложно/нереалистично, я думаю. Я запускаю 150 * 10 симуляций, и аварии происходят в случайные моменты времени (индетерминистические). Я должен написать сценарий, который находит PID всех контроллеров 2 * 14, прикрепляет все эти PID к GDB для каждого из 1500 симуляций. и после каждой симуляции выходим из GDB.Я не думаю, что это самый простой способ выяснить, в чем проблема:/ –

+0

Тогда, может быть, вы можете попробовать установить gdb в качестве программы контроллера ваших роботов и установить в поле controllerArg имя фактического контроллера, который вы хотите для отладки, плюс с опцией -x с командой «запустить», чтобы gdb немедленно запустил контроллер. Тем не менее, я не уверен, что это произойдет, когда один из ваших контроллеров потерпит крах. Я думаю, вы должны запустить веб-страницы из консоли, чтобы увидеть вывод gdb. Сообщите нам, если это приемлемое решение. –

+0

Хмм, я думаю (не был уверен до этого), что segfault полностью разрушает MacPro. Раньше он разбился (я использую TeamViewer для удаленного мониторинга запущенных симуляций MacPro, и в какой-то момент экран затухает, и соединение теряется. Затем мне приходится физически перезагружать MacPro.) Так как это произошло, я надеюсь, что кто-то может перезагрузить MacPro для меня завтра или еще после работы, я буду знать, можно ли это сделать. Я добавил -ggdb в качестве флага компиляции, поэтому мне любопытно Если я могу увидеть более подробную информацию о трассировке стека в отчете по диагностике пользователей сейчас. Будет обновляться, как только я узнаю больше! –