3

Ada で開発されたコードの大部分を含むシングル スレッドの C++ メインのセットがあります。これは Atego (Rational) Apex Duo で構築されており、32 ビット RHEL 6.3 Linux を対象としています。exec は、ソケット、ステート マシン、および exec の心臓部であるタイマー クラスを含む、私が開発したクラス システムです。クラス システムは、ソケットを介して通信する 6 つの異なるシステムで 14 の個別の exec を構築および実行するために使用されます。それらはすべて同じクラス システムを使用し、起動時に INI ファイルに基づいて構成されます。

exec は、gettimeofday を介して Linux システム クロックを使用して 50 または 60 Hz でフレーム化します。

struct timeval {
    time_t      tv_sec;     /* seconds */
    suseconds_t tv_usec;    /* microseconds */
};

目的のスケジューラを生成するためのシンプルな非ビジーウェイト アルゴリズム。

私が現在直面している問題は、これらの exec が (一見) ランダムに失敗することです。失敗は、単にフレーミングを停止したことのようです。すべてのランタイム C++ プロシージャを「try{} catch(...){}」にカプセル化しましたが、何もキャッチされません。同様に、Ada ルーチンは、ヒットしない例外ハンドラーで保護されています。

exec は、多くの場合、失敗するまで 30 分から 1 時間以上問題なく実行されます。メモリ クリープの兆候は明らかではありません (システム モニタを使用)。Atego Rational Graphical Debugger を既に実行中の exec に接続しましたが、役に立ちませんでした。最終的に失敗した場合、コール スタックには何もなく、デバッガ ログの唯一の表示は、アプリケーションが「ステータス 255 で終了しました」ということです。

残念ながら、システムのどこかにある (Linux) システム ルーチンまたはドライバーが Exit を呼び出しています。何かが exit を呼び出しているようです!

この問題をさらに掘り下げる方法を知っている人はいますか?

4

3 に答える 3

2

これはおそらく答えではないはずですが、コメントするには範囲が広すぎます...

したがって、障害は 6 台のマシンそれぞれの 1 つの実行可能ファイルにあります。ネットワークを介したデータ共有を担当する実行可能ファイル。右？そして、「ローカル」実行可能ファイルは信頼できるようです... それとも、6 つの障害のある実行可能ファイルが 6 つのシステムにきれいにマッピングされていないのでしょうか?

障害はネットワークの負荷に関連していますか? たとえば、遅延が (TV または AC 電源) フレーム レートを超えていますか? ネットワークを詰まらせて失敗を早めると、テストが簡素化されます...

Linux ネットワーク クロックが逆方向に実行されたときにシステム障害が発生しました...障害は C++ コンポーネントにあったため、dt が負になったときに簡単な制約エラーは発生しませんでしたが、不条理な「4e9 マイクロ秒でのタイムアウト」が障害からはるかに下回っていました.. .

Ada のタスキング機能と Distributed Systems Annex がこのアプリケーションに理想的であるように思えますが、そのレベルの設計変更はおそらく現段階では適切ではありません。

于 2013-03-24T15:19:19.277 に答える
0

多分それはあなたにいくつかのさらなる方向性を与えることができます:

main から double を返そうとすると、これが発生する可能性があります。見る：

double main ()
{
    return 0.0;
}

$ cc double.c
double.c: 関数 'main' 内:
double.c:2: 警告: 'main' の戻り値の型が 'int' ではありません
$ ./a.out
$ エコー $?
255
$

POSIX OS で main() から double を返そうとすると、呼び出しプロセスはほとんどの場合 255 を参照します。

于 2013-03-23T02:58:30.307 に答える
0

現在、Ada RTS は C++ メインに「満足」していないようです。確かにすべてが答えられているわけではありません...しかし、動作するように修正されています。C++ メインから Ada メインに変更しました...これは単純な変更でした...Ada が C++ の束をインポートするようになったのは、その逆ではありません。それはC++のメインほど手付かずではありません...しかし、かなり機能的だと思います。

未回答の質問は、なぜそれが最初に死んだのかということです...そして、なぜ一部の幹部だけが...他の幹部は「永遠に」走り続けたのですか? 最終的には何かが範囲外になることに関係しているのではないかと考えており、Ada のルーチンの呼び出しでアプリケーションがしなければならないことが多ければ多いほど、アプリケーションはより早く停止します。これにより、スタックが破損していると思われます...しかし、なぜ C++ メインだけでしょうか?

いずれにせよ、それは Ada メインで動作し、動作することが最も重要な要件であるため、「修正済み」と呼んでいます。

于 2013-03-30T13:14:45.673 に答える