2

C/C++ で記述されたアプリケーションがどこで失敗するかを正確に知りたいです。アプリケーションはプログラムによって起動されるため、gdb / lldbを使用したり、IDEを使用したりして、アプリケーションを直接デバッグすることはできません（webotsロボットシミュレーションソフトウェアのロボットコントローラーです）。OSX コンソールでは、クラッシュの瞬間に strack トレースを示す「ユーザー診断レポート」を見つけることができます。ソース コードのどこでクラッシュが発生したかを正確に特定する必要があるだけですが、次のスタック トレース構文がわかりません。

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 行しかなく、コントローラーはデバッグ情報を使用してコンパイルされていないため、ソース コードの行番号にすることはできません。

4

1 に答える 1

1

デバッグするロボット コントローラー プロセスの PID を指定して gdb attach コマンドを使用すると、gdb でロボット コントローラー プロセスをデバッグできます。これにより、gdb はプロセスをオンザフライでアタッチし、最初に gdb から起動されたかのようにデバッグできます。これは、Webots のドキュメント ( http://www.cyberbotics.com/dvd/common/doc/webots/guide/section5.5.html ) で詳しく説明されています。

于 2015-05-29T17:34:26.000 に答える