Segmentation fault after compiling 7.4 on NeuroDebian

Post Reply
bevans

Segmentation fault after compiling 7.4 on NeuroDebian

Post by bevans » Wed Oct 14, 2015 11:17 am

Hi all,
I'm using a Python 3 module with NEURON on NeuroDebian (v8, 64 bit). After a little coercion, I managed to compile from the 7.4 release tar files but get a segmentation fault when I import the neuron module and use certain functions, such as "neuron.h.allsec()".
The simplest way to reproduce the error is with:

Code: Select all

import neuron
neuron.test()
which yields the following output:

Code: Select all

testBytesize (neuron.tests.test_vector.VectorTestCase)
Test that Vector.__array_interface__ returns the proper bytesize (of a double) ... ok
testEndian (neuron.tests.test_vector.VectorTestCase)
Test that Vector.__array_interface__ returns the proper byteorder (endian) ... ok
testNumpyInteraction (neuron.tests.test_vector.VectorTestCase)
Testing numpy.array <=> hoc.Vector interaction ... 
at which point the process crashes the IPython kernel I am running it in.

Looking at /var/logs/syslog I find the following message:

Code: Select all

Oct 14 10:58:59 neurodebian kernel: [ 1301.733007] python3[24472]: segfault at 10 ip 00007f919cf71454 sp 00007ffddf269df0 error 4 in libnrnoc.so.0.0.0[7f919cf3d000+51000]
[edit]
I was using update-alternatives to set the system default version of python to python3.4 and then calling configure with the argument "--with-nrnpython=dynamic". I changed this to "--with-nrnpython=python3" and recompiled which seems to have solved the problem. Are there any disadvantages to specifying a python binary rather than using the "dynamic" flag?
[/edit]
Any help would be appreciated!
Many thanks,
Ben

ted
Site Admin
Posts: 5625
Joined: Wed May 18, 2005 4:50 pm
Location: Yale University School of Medicine
Contact:

Re: Segmentation fault after compiling 7.4 on NeuroDebian

Post by ted » Wed Oct 14, 2015 9:23 pm

It has been a few months since the tar.gz file was created; some change in the interim may have fixed the problem you describe. Suggest discarding what you installed, then download the very latest development code from the mercurial repository and compile that, following the instructions at https://www.neuron.yale.edu/neuron/download/getdevel

bevans

Re: Segmentation fault after compiling 7.4 on NeuroDebian

Post by bevans » Tue Oct 20, 2015 9:58 am

Hi Ted,
Thanks for the advice - after a bit more coercion I managed to compile from the hg repositories using "--with-nrnpython=dynamic" and the segmentation fault is gone - hooray!
Building NEURON for use with Python 3 has been a tricky process though, with a few necessary source-code-hacks before compilation. Would it be possible to incorporate a couple of changes below to make using NEURON with Python 3 a bit easier?
1. Before compilation I had to replace nrn/src/oc/mk_hocusr_h.py with a modified one where the print statements were replaced by print functions with "from __future__ import print_function" at the beginning for backwards compatibility.
2. Similarly, after running build.sh and before calling configure I ran:

Code: Select all

sed -i.bak -e "s/print sys.api_version,/from __future__ import print_function; print(sys.api_version)/" nrn/configure
If these changes could be incorporated upstream so that "mk_hocusr_h.py" and "configure" are built to work with Python 2 or 3 that would be ideal but if that's not possible then the hacks above made compilation work for me (tested so far on OS X and Debian).
Many thanks,
Ben

hines
Site Admin
Posts: 1580
Joined: Wed May 18, 2005 3:32 pm

Re: Segmentation fault after compiling 7.4 on NeuroDebian

Post by hines » Tue Oct 20, 2015 5:58 pm

I changed this to "--with-nrnpython=python3" and recompiled which seems to have solved the problem.
This is the right way, for now, to build with Python3. I have only used --with-nrnpython=dynamic to create binary installers (dmg, setup.exe, deb, rpm) where I don't know what 2.x python installation is
on the target machine but assume that the API is 1013 (ie 2.5-2.7).
Your point about mk_hocusr.h is a good one and I will look into modifying that to work with both Python 2 and 3.
Actually, I'm a bit puzzled how you actually got it to work with the dynamic option and need to experiment with that. From nrn/src/nrniv/nrnpy.cpp I only thought it could only work with python API versions
1013 and 1012.

hines
Site Admin
Posts: 1580
Joined: Wed May 18, 2005 3:32 pm

Re: Segmentation fault after compiling 7.4 on NeuroDebian

Post by hines » Wed Oct 21, 2015 7:28 am

In the context of Python3, I would avoid the --with-nrnpython=dynamic for now. To my astonishment, sys.api_version for Python3.4 is the same
as for Python2.7. I clearly do not understand the meaning of api_version since the module structures for 2.7 and 3.4 are very different.
So my naming convention that ends up with a libnrnpython1013.so is going to have to be rethought since python2 and python3 are incompatible.

The --with-nrnpython=dynamic configure arg is useful when building binary installers since the same api works for 2.5, 2.6, 2.7 and all the popular
packages such as enthought canopy, anaconda, and regular python. This is much more flexible than linking against a specific version of python.
The administrative issues involved in building distributions with several different libnrnpythonXXXX.so libraries (for 2.3 through 3.5) are a bit tedious.
I'll return to this when I get a chance (late December?)

bevans

Re: Segmentation fault after compiling 7.4 on NeuroDebian

Post by bevans » Wed Oct 21, 2015 7:44 am

Hi Michael,
Thanks for clarifying the --with-nrnpython=dynamic configure arg - I'll stick to specifying python3 for now.
Would you like me to send you my modified mk_hocusr.h and the installation script I have written for your reference?
Best,
Ben

hines
Site Admin
Posts: 1580
Joined: Wed May 18, 2005 3:32 pm

Re: Segmentation fault after compiling 7.4 on NeuroDebian

Post by hines » Wed Oct 21, 2015 8:28 am

Would you like me to send you my modified mk_hocusr.h and the installation script I have written for your reference?
Please do. It would be great if one version of mk_hocusr.h worked for both python2 and python3. Otherwise one of the
configure issues will be to convert it early since it is only used to create a src/nrnoc/hocusr.h file and is not installed by
'make install'. As I mentioned,
I have not had time to look deeply into this, but I'm surprised to see that setup.py seems to work in the python3 context.
Unfortunately, I don't remember at the moment what I did vs what is automatic in regard to the 2to3 converter in response to
--with-nrnpython=python3
I must admit that my quick attempt with --with-nrnpython=dynamic when my $PATH gets python3, everything built without
errors (after fixing m4/nrnpython.m4 and '2to3 -w mk_hocusr.h') but I got stuck at the end when launching as there was an error dynamically loading
libnrnpython1013.so even though it built and installed without error.

Post Reply