-
Notifications
You must be signed in to change notification settings - Fork 17
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
umath fails to load #9
Comments
Same behavior with self-built current NumPy. |
With the latest commit that enables raising of import-exceptions in JyNI imports the issue is now also visible on my system. Here it shows up as |
You did quite a good job in identifying the source of this issue. I think I fixed loading of dotted module names in 66a74e0. However umath still doesn't load; now it segfaults at a later point. I'll continue on this front tomorrow or so. |
Great. Just another step forward. I will try your fix at the weekend and report the behaviour with my setup. Same with the other issue. I would then continue to look at the next bug on the way to load umath. I will keep you up to date to avoid duplicate work. |
Sounds good. I already started investigation a bit, but it appears to be a difficult bug. It segfaults at about four different possible locations and has also a small chance of passing through, like your reported about multiarray. |
Also note that since |
…JyObject header. This is needed for extensions such as numpy, which use PyMem_malloc and friends for PyObject allocation (rather than PyObject_malloc and friends). Fixes e.g. issue #9 more or less.
Okay, already fixed it as of 238ba94 I suppose. Took some time, but I traced it around until I concluded it's because |
In my case the program stops, when trying to load _ctypes. But JyNIctypesDemo.sh is also not running. It looks right now, that my setup with the ctypes library is not working. I have to look into that before I a can give an answer to the status of this issue. |
In case it's not just because of an invalid setup, please file a ctypes-scoped issue here. Getting ctypes support stable has even higher priority than NumPy.
What about |
Was just a setup error which I had fixed for the last fork as well, but forgot to mention. On Suse Linux the dyn-load path is different. This line
in JyNI-Lib/ctypes/init.py fixes it. Just add "64". The error message was: ImportError: No module named _ctypes |
Yes, managing Python-path/Jython-path/Java-classpath whatever properly for JyNI is a topic for beta phase I suppose. In general this topic is more complex than just adding the right path, because we will also have to resolve conflicts between native modules and Jython-supplied versions (e.g. datetime and also ctypes so far). Actually this is something we should maybe also discuss on Jython-dev at its time. I suppose your message implies, umath now loads on your system...? |
An import of umath is not succesfull. The program just stops at one point. Reminds me of the deadlock I described in another issue, but I have seen you added the fix. :) Have to look into the details to give a meaningful answer. BTW: import numpy results in this error: NameError: name 'NUMPY_SETUP' is not defined |
Okay. Looking forward to hear about the location it hangs on! Try to add debug output to Regarding |
Still looking into this. Debug output is influencing the behavior of the program control. Therefore limiting down the location is possible, but does not lead to the cause of the error. |
Did you apply jstack to identify the deadlock when it is hanging? (Please consider to post the plain jstack-output here too, so I can also have a look.) |
(fixed the other (maybe unrelated) deadlock issue as of the last two commits) |
… was mentioned in discussion of issue #9. This issue boiled down to sloppy exception insertion in JyNI.java. The old implementation allowed a) exceptions inserted by native code to be rethrown. b) rethrow already caught non-native exceptions, because JyNI.maybeExc misconcepted them as natively inserted exceptions. Both is now solved. Only solving b) made NumPy work, but broke PyOpenGL.
This side-issue is fixed as of ed06aa7. Now |
Fixed the symbol error Now there are issues regarding static vs. dynamic memory detection.
JyNI segfaults on these, because its current detection approach misconcepts them as dynamically allocated PyObjects. It appears that numpy always calls |
With 54c8e16 |
Given that JyNI significantly changed since the last activity here and I cannot reproduce this issue any more for two months or so now, I will close it. |
umath fails to load with the message: AttributeError: _ARRAY_API not found
Cause for this is a bug in JyNI-C/src/Python/import.c in the function PyObject * PyImport_ImportModule(const char *name). The current implementation calls directly the import method from Jythons' builtin class. This leads to the fact, that function calls like
PyImport_ImportModule("A.B.C")
will return the top module A instead of A.B.C as it should be.
In umath this is location in the numpy/core/src/umath/umathmodule.c file within the numpy package
. In the function initumath in the line
PyObject *numpy = PyImport_ImportModule("numpy.core.multiarray");
the variable numpy will ironically be the numpy package and not the multiarray subpackage. Which leads to the observed error, if later the attribute "_ARRAY_API" is checked with this line:
c_api2 = PyObject_GetAttrString(numpy, "_ARRAY_API");
The solution to this bug is to change the function PyImport_ImportModule(const char name) to call PyImport_Import(PyObject module_name) as in the cpython implementation and uncomment the original PyImport_Import(PyObject* module_name) in JyNI-C/src/Python/import.c and let it call the Jython methods after the silly_list has been built up.
In order to do this a comment how these lines
should be called in Jython would be very helpful.
The text was updated successfully, but these errors were encountered: