-
-
Notifications
You must be signed in to change notification settings - Fork 10.8k
Segmentation fault in PyArray_Item_INCREF #7595
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
The problem is that you're repeatedly I embed Python into cpp, and need to use numpy in the embeded python-shell. //c_py.cpp void callpy(int argc, char**argv); int main(int argc, char**argv) void callpy(int argc, charargv) I gdb it and got the following: $ gdb ./c_py GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1 (gdb) run
Finish one call. Do something else. Wait. Python 3.4.3 (default, Oct 14 2015, 20:31:36)
Program received signal SIGSEGV, Segmentation fault. Is there something wrong with NPY_COPY_PYOBJECT_PTR? — |
@njsmith thanks. so I need to find some ways to switch between Python thread and main thread. |
Perhaps? I don't think we have enough information about your problem to really advise, and I guess there are better places for general questions about Python embedding, so closing this. Good luck though. |
For what it is worth, I am seeing this too. |
@scopatz: Are you also using re-initializing CPython and/or using multiple subinterpreters? |
Yeah, I am reinitializing many times. It has only come up in a test suite so far. It isn't hard for me to work around, but a failure mode other than a segfault would have been nice :) |
The problem is that there are a bunch of places inside numpy where it caches Python objects in global variables. To be correct w/r/t reinitialization/subinterpreters, you can never do that, because you might end up using an object that was part of one interpreter with the second interpreter. To fix it we would need to go through and find all these places, and make it so that we're careful to pass around the module object and stash all of them as variables on it. Quite a bit of tricky work, it would likely make numpy slower in general, and most people don't care, so... |
Yeah, don't get me wrong @njsmith. I am not suggesting that this is worth fixing for all of the reason that you mention and more. One python interpreter per process is more stable anyway. I was just offering my experience as a data point. The error message that arises is not indicative of the underlying problem. I do think that is should remain an error, and if there is an easy way to make that apparent that would be great. Even a better error message might not be worth the effort given the small number of people who will ever hit this problem. Presumably, they can find this issue too. |
I embed Python into cpp, and need to use numpy in the embeded python-shell. I get "Segmentation fault" while importing numpy in the second session with python-shell, and the first session with python-shell is ended by Ctrl-D. The following cpp code recall the "Segmentation fault" error.
Using Ubuntu 14.04.4 LTS(64 bit), Python3.4.3, gcc4.8.4, numpy1.11.0
I gdb it and got the following:
Is there something wrong with
NPY_COPY_PYOBJECT_PTR
?NPY_COPY_PYOBJECT_PTR
copy PyObject pointer fromsrc
todst
, sosrc
anddst
need to be pointer to PyObject pointer.NPY_COPY_PYOBJECT_PTR is defined in npy_cpu.h
#define NPY_COPY_PYOBJECT_PTR(dst, src) memcpy(dst, src, sizeof(PyObject *))
but in
34 NPY_COPY_PYOBJECT_PTR(&temp, data);
data
ischar*
. Perhapsdata
would be&data
.But I get some other Segmentation faults after modifying to
NPY_COPY_PYOBJECT_PTR(&temp, &data);
well, deep segfault, deep night.
The text was updated successfully, but these errors were encountered: