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
(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
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion