On Mon, 2005-05-09 at 17:58 -0700, Sebastian Haase wrote:
Hi, Now I'm back to this problem. In the meantime I upgraded again:
na.__version__ '1.4.0' All my python2.2 + numarray + my-extensions work. (Debian Woody) Only my C++ program segfaults. It looked to me like a problem with NA_NewAllFromBuffer -- was there any recent change ?
Yes there was. You can undo it in your private CVS checkout like this: % cd numarray/Src % cvs update -j 1.3 -1.2 libnumarray.ch % cd .. % python setup.py install --genapi --selftest
(I saw that I was using a bytestride of 0 - but it used to work and giving a 1 for that argument still segfaults -- is 0 OK ??)
I don't know for sure. It seems like it should be... just leads to 0 strides.
Now I noticed in the gdb traceback that I chokes is the function deferred_libnumarray_init (( ((#0 0x406d68d5 in PyObject_GetAttrString () from ((/usr/lib/libpython2.2.so.0.0 #1 0x410f905e in ((deferred_libnumarray_init () at Src/libnumarraymodule.c:149
Is this function the standard function that always get called to init numarray (in embedded Python AND using "normal" python) ?
Yes and no. deferred_libnumarray_init() is really for stuff that can't be done at libnumarray.so init time. This is because of circular dependencies. The "real" numarray init function is either "import numarray" in Python or "import_array()" in C. After that, certain calls into the C-API trigger the deferred initialization. deferred_libnumarray_init() is never called directly by application code.
Have you tested this with Python2.2 ?
Yes, using the numarray unit tests. NewAllFromBuffer is also used directly by the numarray ufuncs, so it is tested to a degree by numarray itself. My gut feel is you're hitting an embedding problem, but my gut is only so accurate.
(See for more info below == I did follow Todd's suggestions 1 & 2, but hope not having to recompile python from source.)
That's really not hard. A 5-10 minute exercise usually. Regards, Todd