Crash on exit when using debug builds of Python (static PyObject related)

[jessey-git]

There is a static py::exception object created inside https://github.com/AcademySoftwareFoundation/MaterialX/blob/main/source/PyMaterialX/PyMaterialXCore/PyException.cpp that causes Python debug builds to crash on exit. Static Python objects should not be used as their order of destruction wrt the Python runtime is undefined.

We've confirmed that commenting out the entire function fixes this but obviously that's not a good choice to ship.

Pure python repro: python_d.exe -d "import MaterialX"

 # Child-SP          RetAddr               Call Site
00 00000080`85f7f3b0 00007ffb`78b1d34a     python313_d!_Py_DECREF_DecRefTotal+0x34 [C:\db\build\S\VS1564D\build\python\src\external_python\Objects\object.c @ 280] 
01 (Inline Function) --------`--------     PyMaterialXCore_d!Py_DECREF+0x26 [C:\db\build\S\VS1564D\Debug\python\Include\object.h @ 932] 
02 (Inline Function) --------`--------     PyMaterialXCore_d!Py_XDECREF+0x2b [C:\db\build\S\VS1564D\Debug\python\Include\object.h @ 1042] 
03 00000080`85f7f3d0 00007ffb`78ee9150     PyMaterialXCore_d!pybind11::handle::dec_ref+0x5a [C:\db\build\S\VS1564D\Debug\pybind11\include\pybind11\pytypes.h @ 300] 
04 (Inline Function) --------`--------     PyMaterialXCore_d!pybind11::object::{dtor}+0xc [C:\db\build\S\VS1564D\Debug\pybind11\include\pybind11\pytypes.h @ 396] 
05 00000080`85f7f440 00007ffb`87642c21     PyMaterialXCore_d!`bindPyException'::`2'::`dynamic atexit destructor for 'pyException''+0x10
                                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
06 00000080`85f7f470 00007ffb`876423f5     ucrtbased!<lambda_d121dba8a4adeaf3a9819e48611155df>::operator()+0x131 [minkernel\crts\ucrt\src\appcrt\startup\onexit.cpp @ 206] 
07 00000080`85f7f500 00007ffb`87642547     ucrtbased!__crt_seh_guarded_call<int>::operator()<<lambda_6a47f4c8fd0152770a780fc1d70204eb>,<lambda_d121dba8a4adeaf3a9819e48611155df> &,<lambda_6aaa2265f5b6a89667e7d7630012e97a> >+0x35 [VCCRT\vcruntime\inc\internal_shared.h @ 204] 
08 00000080`85f7f540 00007ffb`87642e34     ucrtbased!__acrt_lock_and_call<<lambda_d121dba8a4adeaf3a9819e48611155df> >+0x57 [minkernel\crts\ucrt\inc\corecrt_internal.h @ 974] 
09 00000080`85f7f5a0 00007ffb`78e7d949     ucrtbased!_execute_onexit_table+0x34 [minkernel\crts\ucrt\src\appcrt\startup\onexit.cpp @ 231] 
0a 00000080`85f7f5f0 00007ffb`78e7e59d     PyMaterialXCore_d!__scrt_dllmain_uninitialize_c+0x19 [D:\a\_work\1\s\src\vctools\crt\vcstartup\src\utility\utility.cpp @ 398] 
0b 00000080`85f7f620 00007ffb`78e7e377     PyMaterialXCore_d!dllmain_crt_process_detach+0x4d [D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\dll_dllmain.cpp @ 182] 
0c 00000080`85f7f660 00007ffb`78e7e70f     PyMaterialXCore_d!dllmain_crt_dispatch+0x67 [D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\dll_dllmain.cpp @ 220] 
0d 00000080`85f7f6a0 00007ffb`78e7e882     PyMaterialXCore_d!dllmain_dispatch+0xff [D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\dll_dllmain.cpp @ 293] 
0e 00000080`85f7f6f0 00007ffb`a7157c87     PyMaterialXCore_d!_DllMainCRTStartup+0x32 [D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\dll_dllmain.cpp @ 335] 
0f 00000080`85f7f720 00007ffb`a7131d00     ntdll!LdrpCallInitRoutine+0x6b
10 00000080`85f7f790 00007ffb`a7131b6d     ntdll!LdrShutdownProcess+0x170
11 00000080`85f7f890 00007ffb`a559da0b     ntdll!RtlExitUserProcess+0xad
12 00000080`85f7f8c0 00007ffb`87641eda     KERNEL32!ExitProcessImplementation+0xb
13 00000080`85f7f8f0 00007ffb`87641e85     ucrtbased!exit_or_terminate_process+0x3a [minkernel\crts\ucrt\src\appcrt\startup\exit.cpp @ 138] 
14 00000080`85f7f920 00007ffb`876421f6     ucrtbased!common_exit+0x85 [minkernel\crts\ucrt\src\appcrt\startup\exit.cpp @ 274] 
15 00000080`85f7f980 00007ff7`4d4a16db     ucrtbased!exit+0x16 [minkernel\crts\ucrt\src\appcrt\startup\exit.cpp @ 288] 
16 00000080`85f7f9b0 00007ff7`4d4a157e     python_d!__scrt_common_main_seh+0x14b [D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 295] 
17 00000080`85f7fa20 00007ff7`4d4a18ae     python_d!__scrt_common_main+0xe [D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 331] 
18 00000080`85f7fa50 00007ffb`a5594ed0     python_d!wmainCRTStartup+0xe [D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_wmain.cpp @ 17] 
19 00000080`85f7fa80 00007ffb`a71ae39b     KERNEL32!BaseThreadInitThunk+0x10
1a 00000080`85f7fab0 00000000`00000000     ntdll!RtlUserThreadStart+0x2b

[kwokcb]

PyShaderRendererc.cpp also appears to have copy-pasted the code and tweaked it.

I think this could work:

Get rid of the static and register the MTLX exception types (as is done for other pybind modules).

1. For this case:
   • also delete the custom translator as it's not needed -- to get the default runtime error handling -- simplest.
   • or keep it and throw the appropriate MTLX exception type.
2. For the renderer wrapper, throw either: a default runtime error, or the registered MTLX exception type

Note: It would be much less confusing to return MTLX exception types as they are exposed but are never returned. You get "lookup exception" for some reason as noted in this issue. ( Python module sample scripts don't all currently even test for lookup exception ).