＃＃＃＃＃＃序文：＃＃＃＃＃＃

組み込み Linux 開発では、コアダンプ ファイルを分析するのが一般的な方法であり、関連する使用方法のチュートリアルがインターネット上でよく見つかります。ただし、マルチスレッド アプリケーションのコアダンプ ファイルを分析する方法に関する記事はほとんどありません。今日は私が実際に使ってみた事例をいくつか紹介し、少しでも皆さんのお役に立てればと思います。コードとスペースの制限により、より特徴的だと思われる問題のみについて説明し、コアダンプ ファイルで発生する多くの状況を解決するためにフレームワークの考え方を使用します。

転載許可と傍観者: WeChat 公開アカウントのフォローを歓迎します: 半妖

または、著者の個人 WeChat を追加します: become_me

あらすじ紹介:

関数をデバッグするときに、いくつかのコアダンプ ファイルを生成しましたが、さまざまなプログラム エラーが発生しました。この機会を通じて、皆さんと共有していきたいと思います。一般に、コアダンプ ファイルは、ヌル ポインタ、配列の範囲外、複数のスレッドによる複数のリリース、スタック オーバーフローなどによって生成される可能性があります。 ここでは、私が遭遇した状況に基づいて代表的な問題をいくつか選択し、簡単な解決策をいくつか紹介します。

まず第一に、それに応じてデバッグするには、gdb ツールを使用する必要があります。コアダンプ ファイルの分析を開始する前に、gdb のさまざまなコマンドに精通する必要があります。以下は、GDB のデバッグについて私が以前に書いた 2 つの記事です: Linux で gdb デバッグを始めるための 1 つの記事 (1)

Linux での gdb デバッグを 1 つの記事で紹介 (2)

したがって、この記事ではこれらの内容については詳しく説明せず、コアダンプ ファイルを分析するときに実行する必要がある実際の操作のみに焦点を当てます。

まず、デバッグにはデバッグ情報が含まれた実行可能ファイルを使用する必要があります。

入力後の最初のことは、bt コマンドを使用してスタック情報を表示することです

リーリー

我们查看对应的第 17帧的堆栈信息

通过上面截图我们可以看到在第17帧中 this这个类实体化的地址出现了问题。

为了对比我们又查看了对应20帧的堆栈信息以及对应帧的详细信息

然后我们需要确认该指针是什么什么出现问题的，进行第20帧数据的详细查看。其中我们用p命令查看该类下面的对应的和17帧this的关系，确认gyro_在这个函数执行的时候，地址是否正确。

从上面来看在此处函数执行的时候，对应的gyro的地址还没有变成错误的0x1388。

从这里我们基本可以确认到，函数从 第20帧对应位置执行之后再到17帧的函数的时候，执行函数的地址发生了改变 然后开始进入校对代码的环节。

这个时候校对不是看代码执行的具体情况，因为发生问题的部分已经是被修改了指针地址。所以我们需要从全局去看这个实体类被进行实体化和释放操作的地方。

最终找到了一个出现线程调用先后顺序导致变量没有准备好，出现的死机情况。

示例二：另一个指针问题

进入之后第一件事情 使用 bt命令查看堆栈信息

这个coredump文件在使用bt命令之后发现 此处的堆栈信息看上去都很正常，无法显示出代码在哪里了出现了问题。

这个时候我们就要考虑多线程时候，堆栈信息不一定直接捕获到对应线程，我们需要打开所有线程里面的堆栈信息。

thread apply all bt

除了bt大家也可以打印自己需要的其他信息

thread apply all command //所有线程都执行命令

对应打印出所有线程的堆栈信息之后，我们就进行一点点查看，但是如果你的代码定义了 信号处理函数，例如我使用了 handle_exit进行处理，然后我就在所有线程堆栈信息里面去搜索对应最后面信号处理的函数，再往回查看程序执行的过程。

此时我们发现led一个实体化类的的初始地址出现了问题，最后校验代码，发现了这个bug。

示例三：内存溢出

进入之后第一件事情 使用 bt命令查看堆栈信息

此时发现当前堆栈信息也无法进行定位到问题。

次に、thread apply all bt を使用しましたが、最初は対応する hand_exit 関数が見つかりませんでした

次に、info locals を使用して、保存されたローカル変数情報を表示します

info f addraddr で指定したフレームの情報を出力します。 info args関数変数の値を出力します。

info locals ローカル変数に関する情報を出力します。

info catch現在の関数の例外処理情報を出力します。

ローカル変数には、ポインター エラーやデータの範囲外の表示を示す明らかな兆候はありません。

そこで、p コマンドを使用して、フレーム情報に保存されている変数情報を出力します。

エラー率が高いと思われるこれらの可変情報を出力することで、判断を支援できます。ただし、この印刷では問題の箇所を確認する方法がありません。

次に、すべてのスレッドのスタック情報を再度確認します。最後に異常なパラメータを確認しましたが、これは非常に大きく、やや異常な値でした。

次に、対応するソースコードの場所を確認しますが、C ライブラリなので、コンパイル場所のコードを直接確認します。

最初にフレーム 7 に表示される情報を確認してくださいstl_algobase.h:465

対応するコードの場所を開いた後、**__n** パラメーターが割り当てられた領域の量のパラメーターであることがわかりました。

実行前後に再確認 stl_vector.h:343

現在渡される __n は、およそ 1 億を超える単位値であり、コードの実際の作業場所には、それほど大きなスペースの割り当ては必要ありません。コードの実行位置と対応する変数のグローバルな使用状況を比較した結果、基本的にはキューが複数のスレッドによって使用されており、ロックが適切に使用されていないと判断され、その結果、ここに問題があることが確認されました。極端な状況下での複数のスレッドの出力および入力操作では、同じ領域で実行されるため、今度はコードがクラッシュします。

これは、私が共有したプロジェクトのコアダンプ ファイルの分析です。より良いアイデアやニーズがある場合は、私を友達として追加して共有してください。 私の記事で使用したコマンドに加えて、gbd のデバッグを支援する他のコマンドを使用してコアダンプ ファイルを確認することもできます。たとえば、アセンブリ コードなどを表示します。インターネット上には、gdb デバッグ コマンドに関する記事がまだたくさんあります。コマンドの使用に役立つ他の記事を読むこともできます。

以上がLinux 開発コアダンプ ファイル分析の実践的な共有の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。