2

以前に機能していたコードを作成していますが、セグメンテーション違反が発生していて、何が問題だったのか理解できません。gdbはエラーをキャッチしますが、明らかな原因を示していません。表示されるソース行は関数名であるため、関数には入りません。命令の分解を見ると、まだスタックを設定しているので、スタックがめちゃくちゃになっている可能性があります。では、これをどのようにデバッグする必要がありますか？これはQNX6.2、コンソールgdbのみにあります。

0x0816b829 in __ml (this=0x79b963c, anMultiplier=0) at ../u_matrix.cpp:56
56      tcMatrix tcMatrix::operator*(float64 anMultiplier)

0x816b820 <__ml>:       push   %ebp
0x816b821 <__ml+1>:     mov    %esp,%ebp
0x816b823 <__ml+3>:     sub    $0x13ac,%esp
0x816b829 <__ml+9>:     push   %edi
0x816b82a <__ml+10>:    push   %esi
0x816b82b <__ml+11>:    push   %ebx
4

6 に答える 6

4

クラッシュしている命令はですpush %edi。

これはおそらく、スタックオーバーフローがあることを意味します。

スタックオーバーフローの考えられる原因の1つは、無限再帰です。(gdb) where関数呼び出しの終わりのないストリームを示している場合、それはあなたの問題です。

where呼び出しの妥当なシーケンスを示している場合は、実行info frameしてup繰り返し、不当に大きいサイズのフレームを探します。

最後に、問題の原因は実行環境の変更であり、プログラムの変更が原因ではない可能性があります。QNXに相当するものが何であるかはわかりませんulimit -sが、スタック制限が小さすぎる可能性があります。

于 2010-07-24T03:32:22.120 に答える
3

雇用されたロシア人の答えに続いて：

ulimit -sはQNXで機能しますが、デフォルトでは無制限です。

私は実験します

ldrel -S2M -L yourexecutablename

初期スタック割り当て/怠惰を調整して、コアダンプが再発するかどうかを確認します。QCCの-Nフラグを使用して、初期スタックサイズを高く設定することもできます。

于 2010-07-24T15:50:38.353 に答える
1

gdbで「bt」を実行する場合に関連するものはありますか？

于 2010-07-23T14:19:17.840 に答える
1

「this」ポインタがめちゃくちゃに見えます-0x79b963cはオフになっているようですが、オブジェクトの初期化方法によっては可能です。試す

印刷*これ

データが意味をなすのか、それともゴミであるのかを確認します。また、ソースが実行可能ファイルと一致していないようです。この例の行は、実行可能ファイルではなく、演算子オーバーライド宣言のように見えます。

特定の行を無視し、ソースで_ml関数全体を探し、いくつかのローカル変数を出力して、ループまたはそれらを含む他のスコープ内にいるかどうかを確認します。

行列がfloatで乗算される行列乗算演算子があると思います-おそらくこれは、範囲外のインデックスのようなものであり、メモリスコープの外で実行されてスタックが破損したある種の問題です。 。

Unknownが言ったように、btも試してみてください-それがたくさんの??（）で戻ってきた場合、あなたは壊れたスタックを持っています。

于 2010-07-23T17:09:47.543 に答える
1

QNX現在はサポートしているように見えますvalgrind（少なくとも6.5以降）：

http://community.qnx.com/sf/frs/do/viewRelease/projects.valgrind/frs.valgrind.valgrind_3_10

于 2015-08-25T10:41:57.730 に答える
-1

また、valgrindを試してみることもできます。これにより、より多くの情報を得ることができます。

于 2010-07-23T14:20:15.593 に答える