ramcdougal
commented
4 years ago What are you trying to do with h.NetCon(5, 12)? That should raise an Exception; does it not?
Closed Helveg closed 1 year ago
ramcdougal
commented
4 years ago What are you trying to do with h.NetCon(5, 12)? That should raise an Exception; does it not?
Helveg
commented
4 years ago Yes, most statements at the start will raise an Exception, I use them inside of unit tests that test whether I catch the RuntimeError and raise semantic Python exceptions like NetConError etc. I've reduced the setup code as much as possible to demonstrate that some of these earlier strange commands like h.NetCon(5,12) probably cause some kind of problem that isn't fixed before the exception is raised and prevent finitialize from functioning later on.
Helveg
commented
4 years ago It gets a lot simpler actually:
Python 3.6.10 (default, Mar 20 2020, 00:41:24)
[GCC 7.5.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from neuron import h
>>> h.NetCon(5, 12)
bad stack access: expecting (double *); really (double)
NEURON: interpreter stack type error
near line 0
objref hoc_obj_[2]
^
NetCon(5, 12)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
RuntimeError: hoc error
>>> h.finitialize()
Segmentation fault (core dumped)
nrnhines
commented
4 years ago These are helpful. Thanks. I will look into the cause.
nrnhines
commented
4 years ago PR #762 is a starting attempt at fixing this in general. Unfortunately HOC's original design for error recovery using longjump is not nearly as adequate as Python's method where every function returns an error indicator on failure. In the above case, the Object structure was created and added to the list of hoc objects before the argument error was noticed, which was before the Object structure was filled by the constructor. Later use of that still empty object generated the segfault. #762 fixes a lot of practical cases, but may fail if the contructor creates new hoc objects itself prior to an error, or if the destructor has trouble with unfilled or partially filled Object.
nrnhines
commented
2 years ago Perhaps this is closable because of #1989
alexsavulescu
commented
1 year ago (venv) savulesc@bbd-cjngk03:~/Workspace/nrn/build$ python
Python 3.10.6 (main, Nov 14 2022, 16:10:14) [GCC 11.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from neuron import h
>>> h.NetCon(0,0)
bad stack access: expecting (double *); really (double)
NEURON: interpreter stack type error
near line 0
objref hoc_obj_[2]
^
NetCon(0, 0)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
RuntimeError: hocobj_call error
>>>
Update: reducing the test setup further revealed that it's just
h.Netcon(n,m)that cause a segfault:(Original post)
Sorry for the issue titles, I have a similar one (https://github.com/neuronsimulator/nrn/issues/434), but they're all just strange segfaults that I encounter when testing, I hope the reports are valuable. If you install the dependencies and copy paste the Setup code into a python session you'll get some python errors and the segmentation fault. The setup code is made up of 2 test files I use: one to check error handling, so it tries to do all kinds of wrong things, and the other for an
IClampwrapper. Seperately they run fine, but together they cause the segfault.Dependencies
Setup
Error