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
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
