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

Crash creating and using OSLCompiler instances in mutliple threads

Đang mở
#1,427 6 bình luận 0 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ó
5/5
Thời gian dự kiến
Hơn một tuần
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

Hướng nghiên cứu

Không có tệp hoặc bài kiểm thử nào được nêu tên. Hãy bắt đầu với SymbolTable::delete_syms() và TypeSpec::struct_list() dùng chung được mô tả trong báo cáo, sau đó theo dõi cách chúng được OSLCompiler và ShadingSystem sử dụng. Công việc được xem là hoàn tất khi có một thiết kế đã được thống nhất về quyền sở hữu hoặc đồng bộ hóa cho các instance đồng thời, cùng bằng chứng cho thấy crash được ngăn chặn.

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

Mô tả

Problem

In the Cycles renderer we are getting crashes doing different renders in different threads, each creating their own OSLCompiler instances. From #654 it appears that this is supposed to work.

I think I understand the cause and am willing to contribute a fix, but looking for advice on the best way to solve this.

What happens is that OSLCompiler ends up calling this in its destructor:

void
SymbolTable::delete_syms()
{
    for (auto& sym : m_allsyms)
        delete sym;
    m_allsyms.clear();
    TypeSpec::struct_list().clear();
}

This TypeSpec::struct_list() is a global variable used by OSLCompiler, and also ShadingSystem. So fully clearing it here is not safe.

I can think of a few solutions:

  1. Never clear this list and accept the memory usage. ShadingSystem does not clear it as far as I can tell, so you already have this when not compiling shaders.
  2. Add reference counting to only clear this list when there are zero classes using it. This also involves adding mutex protection in a bunch of places.
  3. Add a struct list per OSLCompiler and ShadingSystem, instead of making it global.

Solution (3) seems like the best to me, does that seem reasonable? Or is there some performance reason that this should be reused.

Versions
  • OSL branch/version: master branch, 6b6637e
  • OS: Ubuntu Linux
  • C++ compiler: Clang
Ngôn ngữ chính
C++
Star
2.3k
Fork
414
Merge trung bình
4 ngày 2 giờ
Pull request đã merge (30 ngày)
19

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 AcademySoftwareFoundation/OpenShadingLanguage

Tất cả issue của AcademySoftwareFoundation/OpenShadingLanguage

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.