Date 1 - 2 of 2
Crash with shader compiled to memory
We have a weird crash with a shader, compiled on the fly with a OSLCompiler created on the stack, and loaded with LoadMemoryCompiledShader.
The crash occurs later, when calling optimize_group. The compiled shader itself is very simple ( just does out = in ) and its input is connected to a pre-compiled shader.
I ended up using a sanitizer (ASan) and it reports an error during the destruction of the compiler:
==11203==ERROR: AddressSanitizer: new-delete-type-mismatch on 0x60d000064760 in thread T0:
object passed to delete has wrong type:
size of the allocated type: 136 bytes;
size of the deallocated type: 96 bytes.
#0 0xa82280 in operator delete(void*, unsigned long) (/u/devstuff/releases.CentOS-
#1 0x7fc55591c2d8 in OSL_v1_11::pvt::SymbolTable::
#2 0x7fc55590e392 in OSL_v1_11::pvt::SymbolTable::~
#3 0x7fc55590e392 in OSL_v1_11::pvt::
#4 0x7fc55590e4b0 in OSL_v1_11::OSLCompiler::~
#5 0x1100654 in mg::rt::OslShaderConverter::
It seems that when a FunctionSymbol object in the symbol table is deleted, its destructor is not called.
The FunctionSymbol class (symtab.h) is derived from the Symbol class (osl_pvt.h), but Symbol's destructor is not virtual.
We patched our OSL version (1.11.13), just making Symbol's destructor virtual and it solved our problem, no more crashes.
I hope this will help ( and that I'm not wrong somewhere... )!
Thanks for your work,
Apologies for the delay. How about this? https://github.com/AcademySoftwareFoundation/OpenShadingLanguage/pull/1397
I tought it would be safe to do what we did -- the derived classes don't in fact override the destructor and they don't add any fields that need nontrivial teardown. But I agree that we've done something odd here, probably illegal or undefined behavior. I think your solution is probably the simplest and most foolproof approach to fixing.
|1 - 2 of 2|