I noticed this ominous warning on the pybind11 home page: Combining older versions of pybind11 (< 2.6.0) with Python 3.9.0 will trigger undefined behavior that typically manifests as crashes during interpreter shutdown (but could also destroy your data. You have been warned.)
We recommend that you update to the latest patch release of Python (3.9.1), which includes a fix <https://github.com/python/cpython/pull/22670> that resolves this problem. If you do use Python 3.9.0, please update to the latest version of pybind11 (2.6.0 or newer), which includes a temporary workaround specifically when Python 3.9.0 is detected at runtime. I'm not sure if this is related, as it talks about interpreter shutdown, but you are seeing problems with init. Though it could be that there are other problems not yet discovered between various versions of pybind11 and python 3.9. I have seen some problems on my Mac with Homebred-installed Python 3.9 (though nothing as drastic as crashes upon import). I don't remember the details now, but I mostly worked around it by just using Python 3.8 for the time being since VFX is by and large on 3.7 for 2021. > On Dec 30, 2020, at 5:23 PM, Joseph Goldstone <joseph.goldst...@gmail.com> > wrote: > > I built this against the current dev OCIO 2.0, Imath 3_0.26, OpenEXR and > IlmBase 2_5.26, and Python 3.9.0. The first three were all built with an > install prefix of /usr/local/testbed; the latter was installed by pyenv in > ~/.pyenv/versions/3.9.0. The invocation of cmake to create the build dir was > > cmake -DOpenColorIO_ROOT=/usr/local/testbed -DOPENEXR_ROOT=/usr/local/testbed > -DILMBASE_ROOT=/usr/local/testbed -DImath_ROOT=/usr/local/testbed > -DPYTHON_VERSION=3.9.0 -DPython_ROOT=/Users/jgoldstone/.pyenv/versions/3.9.0 > -DCMAKE_INSTALL_DIR=/usr/local/testbed .. > > Trying to load the OpenImageIO module crashed, so I started Python in lldb > this time, The build process puts OpenImageIO.so in > ${CMAKE_INSTALL_PREFIX}/lib/python3.9/site-packages; rather than hand-copy it > to ~/.puenv/versions/3.9.0/lib/python3.9/site-packages, I just added a > reference to its installed location to sys.path. The song goes like this: > > 1263 % lldb ~/.pyenv/versions/3.9.0/bin/python3 > (lldb) target create "/Users/jgoldstone/.pyenv/versions/3.9.0/bin/python3" > Current executable set to > '/Users/jgoldstone/.pyenv/versions/3.9.0/bin/python3' (x86_64). > (lldb) import sys > error: 'import' is not a valid command. > (lldb) run > Process 96002 launched: '/Users/jgoldstone/.pyenv/versions/3.9.0/bin/python3' > (x86_64) > uPython 3.9.0 (default, Dec 29 2020, 16:14:40) > [Clang 12.0.0 (clang-1200.0.32.28)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import sys > >>> sys.path.append('/usr/local/testbed/lib/python3.9/site-packages') > >>> sys.path > ['', '/Users/jgoldstone/.pyenv/versions/3.9.0/lib/python39.zip', > '/Users/jgoldstone/.pyenv/versions/3.9.0/lib/python3.9', > '/Users/jgoldstone/.pyenv/versions/3.9.0/lib/python3.9/lib-dynload', > '/Users/jgoldstone/.local/lib/python3.9/site-packages', > '/Users/jgoldstone/.pyenv/versions/3.9.0/lib/python3.9/site-packages', > '/usr/local/testbed/lib/python3.9/site-packages'] > >>> import OpenImageIO as oiio > OpenImageIO.so was compiled with optimization - stepping may behave oddly; > variables may not be available. > Process 96002 stopped > * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS > (code=1, address=0x10) > frame #0: 0x0000000104b179a3 > OpenImageIO.so`take_gil(tstate=0x0000000100482dc0) at ceval_gil.h:229:51 [opt] > Target 0: (python3) stopped. > (lldb) bt > * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS > (code=1, address=0x10) > * frame #0: 0x0000000104b179a3 > OpenImageIO.so`take_gil(tstate=0x0000000100482dc0) at ceval_gil.h:229:51 [opt] > frame #1: 0x0000000104b181a3 > OpenImageIO.so`PyEval_RestoreThread(tstate=0x0000000100482dc0) at > ceval.c:462:5 [opt] > frame #2: 0x0000000104b65e18 OpenImageIO.so`PyGILState_Ensure at > pystate.c:1378:9 [opt] > frame #3: 0x00000001049087bc > OpenImageIO.so`pybind11::detail::get_internals() + 60 > frame #4: 0x00000001049da7d8 OpenImageIO.so`PyInit_OpenImageIO + 152 > frame #5: 0x0000000100159745 python3`_PyImport_LoadDynamicModuleWithSpec > + 613 > frame #6: 0x0000000100158ff4 python3`_imp_create_dynamic + 308 > frame #7: 0x00000001000871f7 python3`cfunction_vectorcall_FASTCALL + 215 > frame #8: 0x000000010012b660 python3`_PyEval_EvalFrameDefault + 28832 > frame #9: 0x000000010012f004 python3`_PyEval_EvalCode + 2852 > frame #10: 0x0000000100047020 python3`_PyFunction_Vectorcall + 256 > frame #11: 0x000000010012e13b python3`call_function + 411 > frame #12: 0x000000010012b1c6 python3`_PyEval_EvalFrameDefault + 27654 > frame #13: 0x0000000100047115 python3`function_code_fastcall + 229 > frame #14: 0x000000010012e13b python3`call_function + 411 > frame #15: 0x000000010012b1a9 python3`_PyEval_EvalFrameDefault + 27625 > frame #16: 0x0000000100047115 python3`function_code_fastcall + 229 > frame #17: 0x000000010012e13b python3`call_function + 411 > frame #18: 0x000000010012b270 python3`_PyEval_EvalFrameDefault + 27824 > frame #19: 0x0000000100047115 python3`function_code_fastcall + 229 > frame #20: 0x000000010012e13b python3`call_function + 411 > frame #21: 0x000000010012b270 python3`_PyEval_EvalFrameDefault + 27824 > frame #22: 0x0000000100047115 python3`function_code_fastcall + 229 > frame #23: 0x000000010012e13b python3`call_function + 411 > frame #24: 0x000000010012b270 python3`_PyEval_EvalFrameDefault + 27824 > frame #25: 0x0000000100047115 python3`function_code_fastcall + 229 > frame #26: 0x0000000100048539 python3`object_vacall + 489 > frame #27: 0x00000001000487a6 python3`_PyObject_CallMethodIdObjArgs + 246 > frame #28: 0x0000000100157ea2 python3`PyImport_ImportModuleLevelObject + > 1346 > frame #29: 0x0000000100129ad4 python3`_PyEval_EvalFrameDefault + 21780 > frame #30: 0x000000010012f004 python3`_PyEval_EvalCode + 2852 > frame #31: 0x00000001001244f0 python3`PyEval_EvalCode + 64 > frame #32: 0x0000000100172e65 python3`PyRun_InteractiveOneObjectEx + 869 > frame #33: 0x00000001001724e9 python3`PyRun_InteractiveLoopFlags + 169 > frame #34: 0x000000010017240c python3`PyRun_AnyFileExFlags + 60 > frame #35: 0x0000000100191968 python3`Py_RunMain + 2504 > frame #36: 0x0000000100191ce3 python3`pymain_main + 403 > frame #37: 0x0000000100191d3b python3`Py_BytesMain + 43 > frame #38: 0x00007fff6b500cc9 libdyld.dylib`start + 1 > frame #39: 0x00007fff6b500cc9 libdyld.dylib`start + 1 > (lldb) > > Engaging in some minor augury, I exposed the entrails of the .so on a flat > rock in front of the Temple of Jupiter to see what the pigeons might do: > > 1010 % otool -L OpenImageIO.so > OpenImageIO.so: > @rpath/libOpenImageIO.2.3.2.dylib (compatibility version 2.3.2, current > version 2.3.2) > /usr/local/opt/gettext/lib/libintl.8.dylib (compatibility version > 11.0.0, current version 11.0.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current > version 1292.60.1) > > /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation > (compatibility version 150.0.0, current version 1770.255.0) > @rpath/libImath-3_0.26.dylib (compatibility version 26.0.0, current > version 26.0.0) > /usr/local/opt/openexr/lib/libIlmImf-2_5.25.dylib (compatibility > version 25.0.0, current version 25.0.2) > /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version > 1.2.11) > /usr/local/opt/ilmbase/lib/libImath-2_5.25.dylib (compatibility version > 25.0.0, current version 25.0.2) > /usr/local/opt/ilmbase/lib/libIexMath-2_5.25.dylib (compatibility > version 25.0.0, current version 25.0.2) > /usr/local/opt/ilmbase/lib/libHalf-2_5.25.dylib (compatibility version > 25.0.0, current version 25.0.2) > /usr/local/opt/ilmbase/lib/libIlmThread-2_5.25.dylib (compatibility > version 25.0.0, current version 25.0.2) > /usr/local/opt/ilmbase/lib/libIex-2_5.25.dylib (compatibility version > 25.0.0, current version 25.0.2) > @rpath/libIex-2_5.26.dylib (compatibility version 26.0.0, current > version 26.0.1) > @rpath/libIlmThread-2_5.26.dylib (compatibility version 26.0.0, current > version 26.0.1) > /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version > 904.4.0) > 1011 % > > I suppose this could be some sort of RPATH issue — what is RPATH, anyway, at > the time the .so is dynamically loaded into Python — but there’s nothing to > hint about that when the process crashes trying to take the GIL. > > Two questions: > Am I doing something stupid in expecting this sort of thing to work? > Is this the right forum to bring this up, or does one register an issue on > GitHub and if the answer to (1) immediately above is ‘Yes’, no harm done? I > don’t want to leave clutter or debris in GitHub tracking if this is some sort > of rookie mistake. (If neither is the right way to ask for enlightenment, > what *is* the right way?) > > And happy new year to you all! > > > > _______________________________________________ > Oiio-dev mailing list > Oiio-dev@lists.openimageio.org > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org -- Larry Gritz l...@larrygritz.com
_______________________________________________ Oiio-dev mailing list Oiio-dev@lists.openimageio.org http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
