Segmentation Error about pylada-light

[mdavezac]

Could you post the build/CMakeCache.txt file? I've no idea what's going on...

[TomKasel]

CMakeCache.txt

Thank you for the help.

[TomKasel]

I see now why my previous post was so confusing, unfortunately when I posed the question it removed all the text telling which files there was a problem with. Here is the fixed version:

import faulthandler
faulthandler.enable()
import pylada
Fatal Python error: Segmentation fault
Current thread 0x00007fff94454380 (most recent call first):
File "frozen importlib._bootstrap", line 219 in _call_with_frames_removed
File "frozen importlib._bootstrap_external", line 922 in create_module
File "frozen importlib._bootstrap", line 571 in module_from_spec
File "frozen importlib._bootstrap", line 658 in _load_unlocked
File "frozen importlib._bootstrap", line 955 in _find_and_load_unlocked
File "frozen importlib._bootstrap", line 971 in _find_and_load
File "/Users/hms2/bin/pylada-light-master/pkg_install/pylada/crystal/init.py", line 32 in module
File "frozen importlib._bootstrap", line 219 in _call_with_frames_removed
File "frozen importlib._bootstrap_external", line 678 in exec_module
File "frozen importlib._bootstrap", line 665 in _load_unlocked
File "frozen importlib._bootstrap", line 955 in _find_and_load_unlocked
File "frozen importlib._bootstrap", line 971 in _find_and_load
File "frozen importlib._bootstrap", line 219 in _call_with_frames_removed
File "frozen importlib._bootstrap", line 1023 in _handle_fromlist
File "/Users/hms2/bin/pylada-light-master/pkg_install/pylada/init.py", line 131 in module
File "frozen importlib._bootstrap", line 219 in _call_with_frames_removed
File "frozen importlib._bootstrap_external", line 678 in exec_module
File "frozen importlib._bootstrap", line 665 in _load_unlocked
File "frozen importlib._bootstrap", line 955 in _find_and_load_unlocked
File "frozen importlib._bootstrap", line 971 in _find_and_load
File "stdin", line 1 in module
Segmentation fault: 11

[mdavezac]

It's still quite confusing. I'm not what file "pylada/crystal/init.py" actually is, unless something stripped the underscores away.

You could try outside of anaconda. I'll and do the opposive myself.

[breathe]

I ran into this issue when using anaconda python greater than 3.4 on macos mojave. python 3.4 would work and run, but python versions greater than 3.4 would segfault similar to above.

Here's how I was doing the install (doesn't segfault if you change python=3.6 to python=3.4):

brew install git cmake tree
brew cask install gfortran
conda create --name testpylada python=3.6
conda activate testpylada
conda install -y mpi4py numpy ipython cython pytest eigen nbconvert nbformat py jupyter scipy
pip install quantities f90nml pytest_bdd
mkdir build
cd build
cmake -DEIGEN3_INCLUDE_DIR=$CONDA_PREFIX/include/eigen3/ .. 
make

This results in installation which segfault's when I import pylada.

Here's what you see if you run python in lldb and try to import pylada:

lldb $CONDA_PREFIX/bin/python
(lldb) target create "/Users/ncohen/anaconda3/envs/testpylada/bin/python"
run
Current executable set to '/Users/ncohen/anaconda3/envs/testpylada/bin/python' (x86_64).
(lldb) run
Process 58095 launched: '/Users/ncohen/anaconda3/envs/testpylada/bin/python' (x86_64)
iPython 3.6.8 |Anaconda, Inc.| (default, Dec 29 2018, 19:04:46)
[GCC 4.2.1 Compatible Clang 4.0.1 (tags/RELEASE_401/final)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import pylada
Process 58095 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x25)
    frame #0: 0x000000010447cb0b libpython3.6m.dylib`PyUnicode_InternInPlace + 107
libpython3.6m.dylib`PyUnicode_InternInPlace:
->  0x10447cb0b <+107>: movb   0x25(%rax), %r15b
    0x10447cb0f <+111>: movq   0x1d2ac2(%rip), %rax      ; _PyThreadState_Current
    0x10447cb16 <+118>: movb   $0x1, 0x25(%rax)
    0x10447cb1a <+122>: movq   %rbx, %rsi
Target 0: (python) stopped.
(lldb)

I believe the issue has to do with a difference in the way that newer anaconda python distributions are linked against libpython. When building the .py extensions the PythonModule cmake plugin dynamically links against libpython:

https://github.com/UCL/GreatCMakeCookOff/blob/2539e6555acbaed232e1a09935cfb2828fc96b68/scripts/PythonModule.cmake#L138

I believe the newer anaconda extensions statically link against libpython -- when there's a dynamic linker flag on an extension shared library this causes problems at load time.

I'm not sure best way to get the PythonModule cmake plugin to change behavior here -- I forked GreatCMakeCookOff and just commented out the problematic target_link_library call:

https://github.com/breathe/GreatCMakeCookOff/blob/f57d9948f751ccec9023f41536fc269f464d08e5/scripts/PythonModule.cmake#L139

Then these steps seems to work:

brew install git cmake tree
brew cask install gfortran
conda create --name testpylada python=3.6
conda activate testpylada
conda install -y mpi4py numpy ipython cython pytest eigen nbconvert nbformat py jupyter scipy
pip install quantities f90nml pytest_bdd
mkdir build
cd build

cmake \
-DCOOKOFF_GITREPO="https://github.com/breathe/GreatCMakeCookOff.git" \
-DEIGEN3_INCLUDE_DIR=$CONDA_PREFIX/include/eigen3/ \
-DCMAKE_MODULE_LINKER_FLAGS_INIT="-headerpad_max_install_names -undefined dynamic_lookup -bundle -Wl,-search_paths_first -lc++"\
-DCMAKE_SHARED_LINKER_FLAGS_INIT="-headerpad_max_install_names -undefined dynamic_lookup -bundle -Wl,-search_paths_first -lc++" ..

make
ctest -V
make install

For what its worth -- I built a conda package for pylada.

conda create --name testpylada python=3.6
conda install -c breathe -c conda-forge pylada

I'd be interested in contributing the conda package build logic to the pylada project if there is any interest to maintain an official conda package for pylada ...? Or maybe I could try to get the build logic into correct form and see if can get pylada into conda-forge -- I'm new to conda but I think I know enough now to try ... ?

[mdavezac]

A conda recipe would be great, though I rarely use it myself. If cmake fails to detect the right python library, it should be possible to specify them on the command line: -DPYTHON_LIBRARIES="...", and -DPYTHON_INCLUDE_DIRS="...", and -DPYTHON_BINARY_DIR="...". Is it possible to set those things up form the conda recipe?

Back when the whole mechanism was built, cmake would often detect different versions of python for the executable, the library and the include directories, so the great cmake cookoff tries to out-second-guess cmake. Not sure what the current status is.

[breathe]

I believe Those values are all correctly inferred by cmake — it finds the right python headers and libraries (as observed by looking in the cmake cache at least) and specifying those values manually doesn’t change anything. The build proceeds just fine against the anaconda python but segfaults on import of pylada.

I believe the segfault happens because it of the flags used to compile the newer anaconda python releases — seems like can’t have -Llibpython when compiling extension modules for the newer python builds because they are linking to libpython statically from the rest of the extension modules used in the ecosystem and if the loader splices in the dynamic version of the library then bad things happen from the duplicate symbols. At least that’s what I think is going on. I tried a lot of different build settings but couldn’t get anything to work until I changed the line within the PythonModule cmake plugin defined in the great cmake cook off library responsible for including the -Llibpython ...

[mdavezac]

https://gitlab.kitware.com/cmake/cmake/issues/18100

[breathe]

I don't exactly understand what's going on in that discussion but definitely seems relevant! I filed an issue with GreatCMakeCookOff -- maybe someone will provide suggestion for an appropriate workaround.

[mdavezac]

Hopefully, this should be solved with the move to sciki-build in #52