[Numpy-discussion] Re: ANN: numarray-1.2.3 -- segfault in in my C program

[Sebastian Haase]

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