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 ? (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 ??)
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) ? Have you tested this with Python2.2 ? (See for more info below == I did follow Todd's suggestions 1 & 2, but hope not having to recompile python from source.) Thanks Sebastian Haase On Friday 04 March 2005 11:46, Sebastian Haase wrote:
On Friday 04 March 2005 07:03, Todd Miller wrote: From what you're showing me, it looks like libnumarray initialization
is failing which makes me suspect a corrupted numarray installation.
It understood it saying it fails in MyApp::OnInit omx_app.cpp:519 while doing: NA_NewAllFromBuffer (ndim=3, shape=0xbffff2e4, type=tFloat32, bufferObject=0x8a03988, byteoffset=0, bytestride=0, byteorder=0, aligned=1, writeable=1)
the "initialize libnumarray"-stuff is in the 20 lines above that. Do you use NA_NewAllFromBuffer anywhere ?
Thanks, Sebastian Haase
Here are some things to try:
1. Completely delete your existing site-packages/numarray. Also delete numarray/build then re-install numarray.
2. Delete and re-install your extensions. In principle, numarray-1.2.3 is supposed to be binary compatible with numarray-1.1.1 but maybe I'm mistaken.
3. Hopefully you won't get this far but... a python which works well with gdb can be built from source using ./configure --with-pydebug. So a debug scenario is something like:
% tar zxf Python-2.2.3.tar.gz % cd Python-2.2.3 % ./configure --with-pydebug --prefix=$HOME % make % make install
% cd .. % tar zxf numarray-1.2.3.tar.gz % cd numarray-1.2.3 % python setup.py install
% cd .. % tar zxf your_stuff.tar.gz % cd your_stuff % python setup.py install
This makes a debug Python installed in $HOME/bin, $HOME/lib, and $HOME/include. This process is useful for compiling Python itself and extensions with "-g -O0" and hence gdb works better. Besides appropriate compiler switches, debug Python also has more robust object memory management and better tracked reference counting.
Debug like this:
% setenv PATH $HOME/bin:$PATH # export if you use bash % rehash
% gdb python (gdb) run
<do the test>
<crash> (gdb) l <startline>,<endline> # to see some code (gdb) p <some_interesting_variable> (gdb) up # Move up the stack frame to see where the bogus value came from
Regards, Todd
On Thu, 2005-03-03 at 14:40, Sebastian Haase wrote:
Hi, After upgrading from numarray 1.1 (now 1.2.3) We get a Segmentation fault in our C++ program on Linux (python2.2,gcc2.95) , gdb says this:
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1087498336 (LWP 8279)] 0x406d68d5 in PyObject_GetAttrString () from /usr/lib/libpython2.2.so.0.0 (gdb) where #0 0x406d68d5 in PyObject_GetAttrString () from /usr/lib/libpython2.2.so.0.0 #1 0x410f905e in deferred_libnumarray_init () at Src/libnumarraymodule.c:149 #2 0x410f98a8 in NA_NewAllFromBuffer (ndim=3, shape=0xbffff2e4, type=tFloat32, bufferObject=0x8a03988, byteoffset=0, <nl> bytestride=0, byteorder=0, aligned=1, writeable=1) at Src/ libnumarraymodule.c:636 #3 0x0805b159 in MyApp::OnInit (this=0x8108f50) at omx_app.cpp:519 #4 0x4026f616 in wxEntry () from /jws30/haase/PrLin0/wxGtkLibs/ libwx_gtk-2.4.so #5 0x0805a91a in main (argc=1, argv=0xbffff414) at omx_app.cpp:247
To initialize libnumarray I was using this: { // import_libnumarray(); { PyObject *module = PyImport_ImportModule("numarray.libnumarray"); if (!module) Py_FatalError("Can't import module 'numarray.libnumarray'"); if (module != NULL) { PyObject *module_dict = PyModule_GetDict(module); PyObject *c_api_object = PyDict_GetItemString(module_dict, "_C_API"); if (PyCObject_Check(c_api_object)) { libnumarray_API = (void **)PyCObject_AsVoidPtr(c_api_object); } else { Py_FatalError("Can't get API for module 'numarray.libnumarray'"); } } } }
Any idea ?
Thanks, Sebastian Haase