glibc invalid pointer error
fperez.net at gmail.com
Mon Oct 30 16:31:51 CST 2006
On 10/30/06, Travis Oliphant <oliphant at ee.byu.edu> wrote:
> Fernando Perez wrote:
> >This sounds awfully reminiscent of the bug I recently mentioned:
> It actually looks very much like it. I think the problem may be in f2py
> or in one of the C-API calls where-in there is a reference-count problem
> with the built-in data-type objects.
> NumPy won't try to free those anymore which will solve the immediate
> problem, but there is still a reference-count problem somewhere.
> The reference to the data-type objects is consumed by constructors that
> take PyArray_Descr * arguments. So, you often need to INCREF before
> passing to those constructors. It looks like this INCREF is forgotten
> in some extension module (perhaps in f2py or PyMC). It's possible it's
> in NumPy itself, though I've re-checked the code lots of times looking
> for that specific problem.
As a data point, our code has almost no manual memory management in C,
but lots and lots of f2py-generated wrappers, as well as a lot of
We do have hand-written C extensions, but most of them operate on
externally allocated arrays. The one little snippet where we manually
manage memory is a copy of numpy's innerproduct() which I simplified
and tuned for our purposes; it just does:
ret = (PyArrayObject *)PyArray_SimpleNew(nd,dimensions,
if (ret == NULL) goto fail;
[ do computational loop to fill in ret array, no memory management here ]
return (PyObject *)ret;
That's the full extent of our manual memory management, and I don't
see any problem with it, but maybe there is: I copied this from numpy
months ago and haven't really looked again.
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
More information about the Numpy-discussion