制限された場合のプログラムデバッグ
説明組み込み開発では、gdbデバッグが使用できない場合があります.たとえば、 プラットフォームはサポートされていません.例えば、RKのチップを使用していましたが、チップの元工場はgdbデバッグをサポートしていないことを通知し、元工場は移植に成功していません. リソースが制限されています.たとえば、ローエンド製品のリソースが不足したり、一部のリソースが不足したり(メモリ、ストレージスペース、CPUのパフォーマンスが不足したり、物理インタフェースがシリアルポートしかないなど)、gdbが実行できません. 特殊な時期、製品はgdbデバッグを使用できません.例えば、テスト、生産、アフターサービスはgdbデバッグに合格できません. C/C++開発において、gdbの使用はプログラムクラッシュ問題の位置決めに非常に効率的であり、gdbを使用することができず、他のデバッグ手段もない場合、位置決め偶発的なクラッシュ問題は海で針をすくうのと同じであり、有効な情報は非常に少ない. デバッグモード
問題の特定に必要なデバッグ情報 gdbデバッグによっても、他の方法によっても、位置決めの問題にはいくつかの重要な情報が必要です.以下のようにします. で問題が発生したコード行とパラメータ値. 問題が発生したときの関数呼び出しスタック. gdbをサポートし、その他の要因によりgdbが使用できない場合 gdbデバッグは非常に便利で、問題の迅速な位置決めを助けることができます.そのため、この場合、gdbを使用するためにできるだけ条件を作成する必要があります. gdbデバッグを使用するには、コンパイル構成を変更する必要があります.プログラムとライブラリのファイルサイズが大きくなります. gdbserver一部のプラットフォームではgdbが実行できない場合がありますが、gdbserverを試してみてください.ほとんどの組み込みプラットフォームでは、gdbを直接実行するのではなく、gdbserverを使用することを推奨しています. は、デバイスがネットワークをサポートする必要があることを前提としています. 使用方法略. coredump coredumpは、プログラムがクラッシュした後にLinuxカーネルがデバッグ情報を記憶空間に保存するファイルであり、ユーザーは他のプラットフォームでcoredumpファイルを通じてプログラムを分析することができる. 前提: coredumpサポートプログラムのクラッシュ状況. coredumpファイルは一定のストレージスペースを必要とし、ファイルサイズが大きい場合があります. 使用方法略. coredump+最適化使用方法 coredumpを使用すると、次の2つの問題が発生する可能性があります. は-gコンパイルされたプログラムとライブラリを採用し、ファイルサイズが大幅に増加する可能性があります. で生成されたcoredumpファイルは大きく、デバイスは を格納できません.ファイルサイズを小さくするには、strip後のDebugバージョンのプログラムを使用してテストし、stripなしのDebugバージョンのプログラムを使用してcoredumpデバッグを行うことができます.stripバージョンはデバッグ情報とシンボルテーブルを削除しただけですが、2つのプログラムコードセグメント、関数アドレスなどは変化しません.stripプログラムが崩壊した後のcoredump情報はstripなしのプログラムデバッグで使用できます. ファイルストレージは、tmpfs(メモリファイルシステム)を採用し、ファイルをメモリに置くか、NFS(ネットワークファイルシステム)を採用することができ、デバイスが立ち上がった後にネットワークに接続し、自動的にmountリモートディレクトリに接続し、coredumpファイルをリモートディレクトリに格納し、さらにデバイスにテストプログラムを格納せずに直接リモートを実行するプログラムもある. gdbが使用できない場合の大部分がgdbを使用できない場合、他の複雑なデバッグツールも使用できません.通常は、印刷のデバッグ、ログのデバッグなど、コードによってのみデバッグを支援できます. 問題のコード行とパラメータ値の配置 C/C++プログラミングでは、よくあるクラッシュ問題はポインタの問題であり、デバッグ手段を使用していなければ、問題が発生した後に何の情報もなく、どのコードが原因なのか、針をすくうように位置決めするのが難しい. ポインタの問題の一般的な処理方法は、ポインタごとに操作し、ポインタがNULLであるか否かを先に判断することである. 欠陥:空判定操作はプログラムのクラッシュを避けることができるが、問題を隠すこともできる.例えば、予想ポインタは空であることは不可能であるが、ポインタが空になったことに加え、空判定処理後、プログラム実行分岐が予想に合わず、プログラムがクラッシュせず、明らかな現象が発生しない可能性があり、問題が隠される可能性がある. 正しい方法:断言を使用してこの問題を処理することができ、ポインタが空でないと予想される場合、断言判断を加え、問題が発生すると、プログラムがクラッシュした後、クラッシュしたコード行が印刷される.ポインタが空になる可能性がある場合はif判定を使用して印刷を加え、印刷実行ブランチを印刷します. クラッシュの問題はbacktraceを使用して位置決めすることができ、使用方法 .の一般的な問題は、logおよび印刷デバッグ情報によってのみ位置決めできるため、debugフェーズではlog情報が豊富であるほど詳細である. 関数呼び出しスタックの取得は問題のコード行のみを知り,関数の呼び出し関係も不明であり,問題も特定できない. プログラムクラッシュはbacktraceによって関数呼び出しスタックを印刷することができる. 一般的な問題は、logおよびデバッグ情報によってのみ関数呼び出しスタックを決定することができ、debugモードでは、各関数が関数入口で関数名などの情報を印刷することで、印刷関数呼び出しスタックを実現することができる.
問題の特定に必要なデバッグ情報
QT ：Q_CHECK_PTR(m_Loading);
Launcher: UserInterface/MainWidget/WarningWidget/Phone_PopupWidget.cpp:119: void Phone_PopupWidget::hidePopup(): Assertion `m_Loading' failed.