問題タブ [stack-unwinding]

私の例外のメカニズムの研究中に、スタックの巻き戻し中にオブジェクトのフィールドのデストラクタの呼び出しがあることがわかりました。明示的に説明しましょう：

したがって、Lock_ptr のコンストラクターが例外をスローすると、オブジェクトaaは破棄されます。問題は「なぜ」ですか？私は常に、オブジェクトのフィールドは通常の自動 (ローカル) オブジェクトではないと考えていました。それらは、コンストラクターがそれらを初期化する前に作成されます。コンストラクターは作業を終了しました)

Xcode 6 でプロジェクトを完成させました。シミュレーターでテストしました。すべて正常に動作します。ハードウェアにアプリをインストールしました。（iPhone 5）ただし、セグエの準備とセグエの巻き戻しメソッドが呼び出されないように見えます。このプロパティにより、これらのメソッドで設定した値は nil のままです。そして、アプリがクラッシュしました。助けてください。

現在、Unwind を使用してパスのメイン ビューにアクセスしています。

これは、Sender ViewController にあるコードです。

ほぐす前はこんな感じ

これは、ソース ビュー コントローラーからアンワインドした後の様子です。

問題は、緑のトップバーが表示されない理由がわかりませんか? TabBarController と何か関係がありますか?

これは私のパス VC です。

独自の非 GNU クロスプラットフォーム C++ 環境を構築しようとして、スタックの巻き戻しの基本を本当に理解していないという事実に直面しました。私が構築した環境は以下の通りです。

libc++← libc++abi← libunwind(または他のアンワインダー)。

libc++abiある種の libunwind が既に含まれていることがわかりましたが、Linux では使用していません。私が理解したコメントから、それは特別な libunwind: LLVM Stack Unwinder であり、Darwin と ARM のみをサポートし、x86_64 はサポートしていません。CPU アーキテクチャがスタックの巻き戻しプロセスに影響を与えるのはなぜですか?

また、次のスタックアンワインダーについても知っています。

1. glibc 組み込み。
2. libc++abi LLVM libunwind.
3. GNU libunwind (サバンナから)。

質問:

1. プラットフォームまたは CPU アーキテクチャは、スタックの巻き戻しプロセスにどのように影響しますか?
2. 1 つだけでなく、多くのスタック アンワインダーを使用する必要があるのはなぜですか?
3. どのような種類のアンワインダーが存在し、それらの違いは何ですか?

回答からの期待:

各質問の個別のポイントだけでなく、このトピック全体をカバーする回答が得られることを期待しています.

longjmp関数が「アンワインド」する主要な C/C++ 実装はあり__attribute__((__cleanup__(...)))ますsetjmpか。私は特に、このプロパティを持つ POSIX 実装の存在 (または非存在) に関心がありますが、一般的な C/C++ も興味深いものです。

報奨金については、既に言及されている Windows とは対照的に、POSIX 準拠または少なくとも POSIX に似たシステムを探しています。

View Controller からアンワインド アクション セグエを実行しているので、押すと通話履歴の例に移動します。

通話履歴 > プロファイルの詳細 > 通話 (このように動作します)

検索 > プロファイルの詳細 > 呼び出し (この方法ではキャンセル アクションは実行されますが、セグエは実行されません)

セグエの名前は goToHistory と呼ばれ、次を使用して実行されます

ViewController は Exit に接続されているので、上記の方法で呼び出すことができます。

アンワインドを呼び出す方法は次のとおりです。

アンワインド IBACTION を持つ ViewController は通話履歴ですが、[検索] > [プロファイルの詳細] > [通話] から到達したときにわかるように、通話履歴へのセグエを実行しませんが、アクションを実行してから、[通話履歴] > [プロファイルの詳細] > を実行します。通話中

スタックの巻き戻し中に、例外で参照されるローカル変数はどうなりますか? 次のコードを検討してください。

some_local_objectはどうなりますか? スタックの巻き戻し中に破棄されるべきではありませんか? 例に示されているように、安全に使用できますか?

追加の質問

すでに回答されているように、このコードは未定義の動作につながります。それに対する私の2番目の質問は次のとおりです。

ローカル オブジェクトへの参照を渡すことも、そのコピーを作成することも許可されていない場合、まれに bad_alloc が発生する可能性があるためです (これが、gcc 標準ライブラリに意味のあるエラー メッセージ、つまり map.at がない理由だと思います)。 what() が「map.at」を返す例外をスローする場合)、追加情報を渡すための適切な戦略は何ですか? 複数の文字列を結合しても、エラー メッセージの作成中に理論的には bad_alloc が発生する可能性があることに注意してください。すなわち:

Duktape JavaScript インタープリターの Rust ラッパーに取り組んでいます。通常の使用例では、コール スタックは次のようになります。

1. Rust: 任意のアプリケーション コード。
2. Rust: 私のライブラリ ラッパー。
3. C: Duktape の通訳者です。
4. Rust: 私の Rust コード。
5. Rust: アプリケーション コードへの任意のコールバック。

(5) が を呼び出すとどうなりますpanic!か? IRC のさまざまな Rust 開発者によると、panic!(3) のような非 Rust コールフレーム内からの試行は、未定義の動作を引き起こす可能性があります。

しかし、Rust のドキュメントによると、a をキャッチする唯一の方法は、追加のスレッドを生成するpanic!を使用することです。std::task::try他rustrt::unwind::tryの制限の中でも特に、1 つのスレッド内で 2 回入れ子にすることはできません。

Benjamin Herr によって提案された 1 つの解決策は、(5) のコードがパニックになった場合にプロセスを中止することです。私は彼のソリューションを としてパッケージ化しましたがabort_on_panic、「プログラム全体をクラッシュさせますが、少なくとも物事を微妙に破壊することはありません」を含む「仕事」の値に対して、うまくいくようです:

std::task::tryしかし、スレッド/タスク作成のオーバーヘッドなしでエミュレートする方法はありますか?