0

RED Hat Linux でのセグメンテーション エラーが原因で、C++ アプリケーションがクラッシュする問題に直面しています。C++ に埋め込まれた Python を使用しています。

私の限界以下を見つけてください

  1. アプリケーションがクラッシュする本番マシンにアクセスできませんか。アプリケーションがクラッシュすると、クライアントからコア ダンプ ファイルが送信されます。
  2. 問題は、本番マシンとまったく同じ構成のテスト マシンでは再現できません。
  3. 1 時間後、4 時間後、1 日後、または 1 週間後にアプリケーションがクラッシュすることがあります。アプリケーションがクラッシュする時間枠や特定のパターンはわかりません。
  4. アプリケーションは複雑で、埋め込まれた Python コードはアプリケーション内のさまざまな場所で使用されます。広範なコード レビューを行いましたが、コード レビューを行っても修正を見つけることができませんでした。
  5. コア ダンプのスタック トレースによると、乗算操作の周りでクラッシュしています。コード内のそのような操作のコードを確認しましたが、そのような操作が実行されるコードは得られませんでした。そのような操作は、組み込みの python から実行された python スクリプトを介して呼び出され、制御できないか、確認できない可能性があります。
  6. Valgrind のような本番環境ではプロファイリング ツールを使用できません。
  7. ローカル マシンで gdb を使用して、コア ダンプを分析しています。本番マシンで gdb を実行することはできません。

私たちが行った取り組みを以下に示します。

  1. 問題を再現するために、ログを分析し、テスト環境でアプリケーションに送信されるリクエストを継続的に発行しました。
  2. ログにクラッシュ ポイントが記録されていません。毎回異なるログを取得します。私はこれが原因だと思います; メモリが別の場所で破壊され、しばらくするとアプリケーションがクラッシュします。
  3. アプリケーションの任意の時点で負荷をチェックしましたが、アプリケーションの制限を超えることはありません。
  4. アプリケーションのメモリ使用率も正常です。
  5. テスト マシンで Valgrind を使用してアプリケーションのプロファイリングを行い、valgrind エラーを削除しましたが、アプリケーションはまだクラッシュしています。

問題を解決するためにさらに先に進むための助けをいただければ幸いです。

以下、バージョン詳細

Red Hat Linux サーバー 5.6 (Tikanga) Python 2.6.2 GCC 4.1

以下は、彼らが (私のマシンで) 共有したコア ダンプ ファイルから取得したスタック トレースです。参考までに、コア ダンプ ファイルで gdb を実行するために実稼働マシンにアクセスすることはできません。

0  0x00000033c6678630 in ?? ()
1  0x00002b59d0e9501e in PyString_FromFormatV (format=0x2b59d0f2ab00 "can't multiply sequence by non-int of type '%.200s'", vargs=0x46421f20) at Objects/stringobject.c:291
2  0x00002b59d0ef1620 in PyErr_Format (exception=0x2b59d1170bc0, format=<value optimized out>) at Python/errors.c:548
3  0x00002b59d0e4bf1c in PyNumber_Multiply (v=0x2aaaac080600, w=0x2b59d116a550) at Objects/abstract.c:1192
4  0x00002b59d0ede326 in PyEval_EvalFrameEx (f=0x732b670, throwflag=<value optimized out>) at Python/ceval.c:1119
5  0x00002b59d0ee2493 in call_function (f=0x7269330, throwflag=<value optimized out>) at Python/ceval.c:3794
6  PyEval_EvalFrameEx (f=0x7269330, throwflag=<value optimized out>) at Python/ceval.c:2389
7  0x00002b59d0ee2493 in call_function (f=0x70983f0, throwflag=<value optimized out>) at Python/ceval.c:3794
8  PyEval_EvalFrameEx (f=0x70983f0, throwflag=<value optimized out>) at Python/ceval.c:2389
9  0x00002b59d0ee2493 in call_function (f=0x6f1b500, throwflag=<value optimized out>) at Python/ceval.c:3794
10 PyEval_EvalFrameEx (f=0x6f1b500, throwflag=<value optimized out>) at Python/ceval.c:2389
11 0x00002b59d0ee2493 in call_function (f=0x2aaab09d52e0, throwflag=<value optimized out>) at Python/ceval.c:3794
12 PyEval_EvalFrameEx (f=0x2aaab09d52e0, throwflag=<value optimized out>) at Python/ceval.c:2389
13 0x00002b59d0ee2d9f in ?? () at Python/ceval.c:2968 from /usr/local/lib/libpython2.6.so.1.0
14 0x0000000000000007 in ?? ()
15 0x00002b59d0e83042 in lookdict_string (mp=<value optimized out>, key=0x46424dc0, hash=40722104) at Objects/dictobject.c:412
16 0x00002aaab09d5458 in ?? ()
17 0x00002aaab09d5458 in ?? ()
18 0x00002aaab02a91f0 in ?? ()
19 0x00002aaab0b2c3a0 in ?? ()
20 0x0000000000000004 in ?? ()
21 0x00000000026d5eb8 in ?? ()
22 0x00002aaab0b2c3a0 in ?? ()
23 0x00002aaab071e080 in ?? ()
24 0x0000000046422bf0 in ?? ()
25 0x0000000046424dc0 in ?? ()
26 0x00000000026d5eb8 in ?? ()
27 0x00002aaab0987710 in ?? ()
28 0x00002b59d0ee2de2 in PyEval_EvalFrame (f=0x0) at Python/ceval.c:538
29 0x0000000000000000 in ?? ()
4

3 に答える 3

3

ほとんどの場合、デバッグが非常に困難な C++ コードのポインターで何か悪いことをしています。

  • スタック トレースが適切であると想定しないでください。関連する可能性がありますが、ポインターの誤用は、しばらくしてクラッシュすることがよくあります
  • 完全な警告をオンにしてビルドします。コンパイラは、ローカルへの参照を返すなど、明らかでないポインターの誤用を指摘できます。
  • アレイを調査します。配列をstd::vector(C++03) または(C++11) に置き換えて、と をstd::array使用して反復処理し、 を使用してインデックス付けできるようにしてください。begin()end()at()
  • ポインターを調査します。std::unique_ptrそれらを(C++11) に置き換えるか、可能な限り置き換えます(boost::scoped_ptrリリース ビルドにオーバーヘッドがないはずです)。残りをshared_ptrまたはに置き換えweak_ptrます。置き換えられないものは、おそらく問題のあるロジックの原因です。

まさにあなたが見ている問題のために、最新の C++ では、ほとんどすべての生ポインタの使用を完全に削除することができます。それを試してみてください。

于 2013-01-24T14:20:11.633 に答える
1

まず最初に、バイナリとlibpythonデバッグシンボルの両方をコンパイルしてプッシュします。スタックトレースは、追跡がはるかに簡単になります。

に関連する引数g++はです-g

于 2013-01-24T14:03:03.650 に答える
1

提案:

  • すでに提案されているように、完全なデバッグ ビルドを提供します。
  • メモリ テスト ツールと CPU 拷問テストを提供する
  • コア ダンプの解析時に Python ライブラリのデバッグ シンボルを読み込む
  • スタックトレースは eval() に関する何かを示しているので、動的なコード生成と評価/実行を行っていると思います。その場合、このコード内または渡された引数に、実際のエラーがある可能性があります。コードとコード ダンプへの任意のインターフェイスでのアサーションが役立つ場合があります。
于 2013-01-24T14:16:50.520 に答える