1. mumurik
  2. xyzzy
  3. Issues
Issue #41 on hold

make-frameとdelete-frameを連続して実行すると致命的な例外が発生する

xyzzy_17_638
created an issue

== 再現方法 == 以下のコマンドラインで起動を行う {{{ xyzzy.exe -q }}} {{{scratch}}} で以下のコードを実行する {{{ (delete-frame (make-frame)) }}}

== 期待する動作 ==

  • 何も起きない ** 内部動作としては、フレームが生成され、直後に削除される

== 実際の動作 ==

  • 致命的な例外が発生する

== 再現バージョン == * 0.2.3.8 ~ 0.2.3.9.1

== 動作するバージョン == * 0.2.3.7 までの全てのバージョン

Comments (12)

  1. xyzzy_17_638 reporter

    すみません。ちょっとコード見る時間が取れなくて進展してません。

    あてずっぽうで言うと、遅延処理とdelete-frameの整合性の問題じゃないかと予想してます。

  2. xyzzy_17_638 reporter

    ちょびちょびとしか時間とれてませんorz

    以下は途中経過です

    再現方法

    • frame.cc:delete_floating_app_frame()のfor()ループの内の先頭にブレークを置き、ここで delete した app1 をログに残しておく
    • frame.cc:call_all_startup_frame_second()のfor()ループの内の先頭にブレークを置き、得ている app1 の値をログに残しておく

    以上の操作を行ったあと、(delete-frame (make-frame))を実行する。

    • まず delete_floating_app_frame() で app1 が消される
    • その後call_all_startup_frame_second() で↑と同じポインタ値を持つ app1 が操作対象となる
      • change_root_frame() が呼び出され、例外が発生する

    0.2.3.7 で動いているのはなぜ?

    0.2.3.7 での動作順は 0.2.3.8 以降と異なり、 call_all_startup_frame_second()が先に実行され、 その後delete_floating_app_frame()が実行される。

    # これが期待する動作順序なのかも?

    TODO

    • 差分を見つつ原因を探る
    • どう直すかを相談する
  3. mumurik repo owner

    なるほどなぁ。second phaseのhookが呼ばれてからdeleteが呼ばれるのが期待動作だろうなぁ。 まぁdeleteの前にもよんどきゃいいんじゃないかのぅ。ちと試してみます。

  4. mumurik repo owner

    ダメだ。floatingの前にcall_all_startup_frame_second呼ぶだけで落ちちゃうね。 second phaseのinitのpendingのリストには残ってるが、app-frameのlistには残ってないからrootを差し替えようとして落ちる、か。

    どうしたらいいのかなぁ。second phaseのinitが来る前に消しちゃう、でいいかなぁ。 frameが作られていながらhookが呼ばれなくなるケースがある訳だが、もともとこのhookはevalを抜けてから呼ばれる事を意図している訳で、その前にdeleteされてるのだから呼ばれなくてもまぁいい気もする。

    deleteの時にg_startup_second_pending_framesからも抜けばいいって事だと思うが、今日は時間切れ。

  5. mumurik repo owner

    change_root_frameの前にfloatingの方に入ってるかチェックー>入ってたら何もしない、ってコードを入れるが正解な気がしてきた。 これは私が引き取ります。

  6. Log in to comment