Page MenuHome

Crash when importing python modules on MacOS
Closed, InvalidPublic

Description

System Information
MacOSX El Capitan, 10.11.6, 3.5GHz i7, 32GB Ram

Blender Version
Broken: 2.78 0e5089c, I tried with versions as old as 2.71 b984489
Worked: this problem doesn't appear on Linux and Windows under the same conditions

Short description of error
Crash when importing some Python modules

Exact steps for others to reproduce the error
Prior to this, install vtk (for instance with homebrew)
Run this: brew install vtk --with-python3 --without-python

Open Blender, go in its Python Console
Write the following:
import sys
sys.path.append('/usr/local/Cellar/vtk/7.0.0_2/lib/python3.5/site-packages')
import vtk
Results in direct crash

Comments
A colleague wrote an open source library for neuroscience files parsing called Brain, it also uses Boost.
We built his library on my iMac with python bindings and then the very same behaviour happened: crash at import time

When I open a regular python3 in my Terminal, I import vtk or brain or other libraries without problem.
I am not familiar with C++ but somebody told me this might be related to incompatible Boost versions or something similar.

I attached the trace I get after Blender 2.78 crashes on my iMac if that helps.

Details

Type
Bug

Event Timeline

Sergey Sharybin (sergey) lowered the priority of this task from Needs Triage by Developer to Normal.Oct 4 2016, 3:03 PM

Not sure if that's something to do with symbol collision, but hard to give any specific info without being able to reproduce the issue with debug version of Blender.

Might also be difference in particular version of Python the module is linked against.

@Martijn Berger (juicyfruit), @Brecht Van Lommel (brecht): you have more direct access to OSX, might having a check if there's something wrong from Blender side?

I'm sorry, I fail to see where this is related to Windows stuff with .dll...

In this T49508 ticket, some people talk about creating a new installer but Blender for MacOS comes as precompiled and ready to use.
Does this mean that at some point you will recompile Blender for MacOS and the problem will be solved?

Sorry, wrong task number xD

can you do a:

otool -L /usr/local/Cellar/vtk/7.0.0_2/lib/python3.5/site-packages/vtk/vtkFiltersCorePython.so

it might be linked against a wrong python version

Here's my result with the above otool command line:

/usr/local/Cellar/vtk/7.0.0_2/lib/python3.5/site-packages/vtk/vtkFiltersCorePython.so:
/usr/local/Cellar/vtk/7.0.0_2/lib/libvtkFiltersCorePython35D-7.0.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/local/Cellar/vtk/7.0.0_2/lib/libvtkFiltersCore-7.0.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/local/Cellar/vtk/7.0.0_2/lib/libvtkCommonExecutionModelPython35D-7.0.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/local/Cellar/vtk/7.0.0_2/lib/libvtkCommonExecutionModel-7.0.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/local/Cellar/vtk/7.0.0_2/lib/libvtkCommonDataModelPython35D-7.0.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/local/Cellar/vtk/7.0.0_2/lib/libvtkCommonDataModel-7.0.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/local/Cellar/vtk/7.0.0_2/lib/libvtkCommonMiscPython35D-7.0.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/local/Cellar/vtk/7.0.0_2/lib/libvtkCommonMisc-7.0.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/local/Cellar/vtk/7.0.0_2/lib/libvtkCommonSystemPython35D-7.0.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/local/Cellar/vtk/7.0.0_2/lib/libvtkCommonSystem-7.0.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/local/Cellar/vtk/7.0.0_2/lib/libvtkCommonTransformsPython35D-7.0.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/local/Cellar/vtk/7.0.0_2/lib/libvtkCommonMathPython35D-7.0.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/local/Cellar/vtk/7.0.0_2/lib/libvtkCommonTransforms-7.0.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/local/Cellar/vtk/7.0.0_2/lib/libvtkCommonMath-7.0.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/local/Cellar/vtk/7.0.0_2/lib/libvtkCommonCorePython35D-7.0.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/local/Cellar/vtk/7.0.0_2/lib/libvtkWrappingPython35Core-7.0.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/local/opt/python3/Frameworks/Python.framework/Versions/3.5/Python (compatibility version 3.5.0, current version 3.5.0)
/usr/local/Cellar/vtk/7.0.0_2/lib/libvtksys-7.0.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/local/Cellar/vtk/7.0.0_2/lib/libvtkCommonCore-7.0.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.1.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1226.10.1)

Blender is still compiled with the deprecated libstdc++ ABI on MacOS. there is an agreement between the developers not to change this for the 2.7x series. As such this will not be fixed anytime soon.

You could compile all this by hand and patch it where needed to link against libstdc++ by hand or use older version.

If the problem here is indeed C++ symbol collisions, couldn't we just hide all those symbols? Adding *__Z* in osx_locals.map should hide all Blender C++ symbols. We already hide Boost symbols but maybe there are some that we missed.

As far as I know an extension build with libc++ can work even if Blender is built with libstdc++, as long as we keep the symbols from interfering.