Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

FunctionReference destructor called on wrong thread

オープン
  • 何か問題がありますか？
#99 コメント 1 件 リアクション 1 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
35/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
停滞
技術スタック
cpp, javascript
領域
api, backend

調査の方向性

Start with TimeoutDispatcher::CallFunction and the FunctionReference ownership described in the issue, then trace how TimeoutDispatcher::ThreadedFunction releases the last reference. Exercise the setTimeout and Window polyfill path with several closely spaced events on macOS. Done means FunctionReference destruction and napi_delete_reference consistently occur on the JS runtime thread without the CHECK_ENV failure.

索引モデルが issue の本文から書いたものです。

説明

Describe the bug
I'm occasionally seeing shared_ptr ref counts to FunctionReference's going to zero inside the TimeoutDispatcher's ThreadedFunction. This triggers the destructor for the FunctionReference which is not on the JS runtime thread. This can cause the CHECK_ENV assert to fail when calling napi_delete_reference.

To Reproduce
I think this specifically happens with functions given to setTimeout when using the Window polyfill. I haven't been able to repro it with a minimal example, but it seems to happen when I have a bunch of setTimeout events that go off near each other. e.g., If I have a bunch of dispose() calls on scene objects in my render loop for several frames in a row.

Expected behavior
It looks like most of the time, the ref count to the shared pointer goes to zero inside the thread managing the js runtime, so the call to napi_delete_reference runs correctly.

Screenshots
Here's a sample stack trace where the assert fails.
Screenshot 2024-10-02 at 10 02 43 AM

Other

  • Platform: macOS

I played around with some modifications and got something to work a little more reliably. In particular, I think the std::shared_ptr is very confusing to debug when this particular object has to be destructed in a very particular location. I think a std::unique_ptr makes it much more clear how to ensure the object is destructed on the correct thread. The only reason a unique_ptr wasn't used I believe is because the dispatcher needs a std::function with a lambda capturing the smart pointer. Since std::function is copyable, it can't have a lambda that has move-captured a unique_ptr.

I instead came up with this:

    void TimeoutDispatcher::CallFunction(std::unique_ptr<Napi::FunctionReference> function)
    {
        if (function)
        {
            // Since we need a std::function and a std::function is copyable, we can't
            // just move-capture the unique_ptr when forming the lambda.  Instead, release
            // the raw pointer, capture it in the lambda, and then make sure to delete it
            // manually when we're done.
            auto ptr = function.release();
            auto fn = [ptr](Napi::Env env) {
                try {
                    ptr->Call({});
                    delete ptr;
                } catch (...) {
                    delete ptr;
                    throw;
                }
            };
            m_runtime.Dispatch(std::move(fn));
        }
    }

I also double checked the ref count on the version with the shared_ptr and it always appears to be 1 once it reaches CallFunction, even in the event that the assert is failed.

主要言語
C++
スター
22
フォーク
23
平均マージ
2時間 29分
マージ済み PR（30日）
3

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

BabylonJS/JsRuntimeHost のほかの issue

BabylonJS/JsRuntimeHost の issue をすべて見る

似ている issue

C++ の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。