問題タブ [stack-unwinding]

Windowクラスのインスタンスを作成したとします。ウィンドウがユーザーに表示されます。次に、例外がスローされ、インスタンスへの参照が失われますが、インスタンスがまだ存在するため、ウィンドウは引き続きユーザーに表示されます (参照されなくなっただけです)。

これらの状況で何をすべきか？

具体的には、Squirrel スクリプト言語 (http://www.squirrel-lang.org/) について話しています。finallyJavaとは逆にブロックやファイナライザメソッドがないようなので、この言語では例外処理が壊れているのでしょうか?

最近、この C++/Lua エラーに出くわしました

エラーはluaL_erroruselongjmpであるため、スタックが巻き戻されたり、s破壊されたりして、メモリ リークが発生することはありません。スタックの巻き戻しに失敗する Lua API が他にもいくつかあります。

明らかな解決策の 1 つは、Lua を C++ モードで例外を使用してコンパイルすることです。ただし、Luabind には標準の C ABI が必要なため、できません。

私の現在の考えは、Lua API の厄介な部分を模倣する独自の関数を作成することです。

だから私の質問:function_for_luaのスタックは適切に巻き戻されていますか? 何か問題が発生する可能性はありますか?

関数 F() の開始時に作成する単純な C++ オブジェクトがあり、オブジェクトのコンストラクターとデストラクターを使用して、一致する 2 つの関数 (OpDo、OpUndo) が F() の開始時と戻り時に確実に呼び出されるようにします。ただし、F() の本体内で例外がスローされた場合に備えて、操作を元に戻したくありません。これはきれいに行うことができますか？std::uncaught-exceptionについて読んだことがありますが、その使用は推奨されていないようです。

libunwindは、FreeBSD 8.1 amd64でパッケージ（pkg_add -r libunwind）として利用できます。

FreeBSD8.1i386ではそのようには利用できません。

http://www.nongnu.org/libunwind/からダウンロードすると、ビルドできません。

エラーは、ptrace / _UPT_elf.c：4からインクルードされたファイルにあります：../ include / libunwind_i.h：65：5：エラー：#errorホストのバイト順序が不明です。 *エラーコード1

これは./configureエラーのようです。構成時にこの情報を強制する方法はありますか？

catch/tryが使用できない場合 (つまり、巻き戻し先のコードが制御不能な場合) 、スタックを任意のレベルに巻き戻したいと考えています。これは可能ですか？

たとえば、テストでは、前提条件をチェックするメソッドをテストで呼び出し、それらの前提条件が満たされていない場合はテストの呼び出し元に巻き戻したいと思います (resume at caller[1])。catchテスト ハーネスが制御不能になっているため、適切な場所にブロックを設定できません。

DWARF2 デバッグ形式では、.debug_frame セクションにある CFI (Call Frame Information) の助けを借りて、スタックの巻き戻しがサポートされます。これはまさに、すべてのレジスタが前のフレームで値を取得するためのルールを保持するテーブルです。ただし、これらのルールはすべて、レジスタがスタック上のある場所に保存されるという事実に依存しています。これは、フレーム ポインターがない場合に前のフレーム レジスターでスタック ポインターの値を取得する場合には当てはまりません。このような場合、スタック ポインタはスタックに保存されず、その値をインクリメントおよびデクリメントするだけで管理される場合があります。ただし、dwarf2 (または一般的には dwarf 形式) では、レジスタ値が現在の値を超える式であることを示す方法はありません。したがって、私の質問は、dwarf2 デバッグ形式でスタックの巻き戻し中にスタック ポインターの値を取得する方法です (フレーム ポインターがない場合)。

-BV

次の落とし穴はありますか。

dwarf2でスタックを巻き戻すことで、いくつかの非常に基本的なABI（アプリケーションバイナリインターフェイス）シナリオで引数の信頼性の高い回復がどのように保証されるかを理解していません。ABIについて考えてみましょう。これは、最初の3つの引数がレジスターにあり、スタックにある必要があることを示しています。私が理解しているように、dwarf2スタックの巻き戻しメカニズムにより、CFIテーブルが適切に満たされている場合、現在のフレームの呼び出しポイントでレジスタの値を取得できます。ただし、これでは、呼び出し元のプロローグに移動して、引数レジスタの内容を知ることはできません。したがって、同じフレーム内の異なるポイントでもレジスタの値を見つける方法があったはずです（.debug_frameセクションでエンコードされたテーブルは、前のフレームの場所のみを示しています）。

私の理解に何か問題がありますか？このような場合、dwarf2デバッグ形式に基づくデバッガーはどのように機能しますか？引数がスタックで渡されるアーキテクチャの場合、プログラム内のすべてのポイント（任意のフレーム）で値を回復するための問題はありません。

TIL RAII とスタック巻き戻しの「絡み合い」(より適切な言葉がないため) の私の概念は、(完全ではないにしても) かなり間違っています。私の理解では、RAII を使用すると、未処理の例外が原因である可能性があるものであっても、あらゆる/すべてのリソース リークを防ぐことができます。

ただし、このテスト プログラムを作成し、その後この記事/ドキュメントに出くわしたことで、スタックの巻き戻しは、たとえば、外部/その他のスコープ内の自動ではなく、try ブロック内の自動リソースに対してのみ、RAII 対応のリソースの割り当て解除が開始されることに気付きました。 .

この（新しい）理解は正しいですか？それとも、私がまだ把握していないニュアンスがありますか? そこにチャイムを鳴らしたいグルはいますか？適切な記事/分析/説明 (スタックの巻き戻しの) へのポインタは、役に立ちます/高く評価されます…</p>

C ++では、スタックを巻き戻した後もポインタは有効なままですか？