Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

FunctionReference destructor called on wrong thread

Đang mở
  • Có gì không ổn?
#99 1 bình luận 1 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
35/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Đình trệ
Công nghệ
cpp, javascript
Lĩnh vực
api, backend

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
C++
Star
22
Fork
23
Merge trung bình
6 giờ 17 phút
Pull request đã merge (30 ngày)
4

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của BabylonJS/JsRuntimeHost

Tất cả issue của BabylonJS/JsRuntimeHost

Issue tương tự

Thêm issue về C++

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.