[Pyublas] core dump when including pyublas/numpy.h in C++ code not driven from python

[Christophe Koudella]

Hi again,

thanks again for helping us understand what the philosophy behind your
package is. You are right that templated signatures might be the best
solution,
hovever we ran into another issue.

One of our users here did a #include <pyublas/numpy.h> in a piece of code
that he compiled into a C++ binary executable on unix. He then ran the
binary
and witnessed a core dump. The stack trace seemed to reveal that runtime
attempts
were made to call various python functionalities, which of course could not
be done since
he was running a pure C++ program which has no knowledge of any python
interpreter.
Note that the above include is the only reference to pyublas, i.e. there was
no attempt
(yet) to create any numpy_vector array or anything in this program.

Again I apologize for my sketchiness in describing the issue and I may get
back later
to be more explicit.

However, can you let me know if your package is meant to be used exclusively
from
python? As I said in my last post, we write C++ code that is called from
other C++
code, or that may provide services to other clients, not necessarily python
apps.

If it is the case that pyublas is inextricably linked to a python
interpreter, then would
that mean that whenever we want to benefit from pyublas handle semantics
when calling
from python, we would have to write some kind of interface layer, callable
only from
python and which would call into pyublas agnostic C++ code? Am I seeing this
right?

Also, if satisfied with value semantics, then can we nevertheless expose
pure-ublas signed
C++ functionality to python without any reference to pyublas on the C++
side? (Actually,
I can try that out myself, but you probably know that anyway.)

Thanks,
Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tiker.net/pipermail/pyublas/attachments/20091022/7b5fe3d8/attachment.htm>

[Andreas Klöckner]

Post by Christophe Koudella
Hi again,
thanks again for helping us understand what the philosophy behind your
package is. You are right that templated signatures might be the best
solution,
hovever we ran into another issue.
One of our users here did a #include <pyublas/numpy.h> in a piece of code
that he compiled into a C++ binary executable on unix. He then ran the
binary
and witnessed a core dump. The stack trace seemed to reveal that runtime
attempts
were made to call various python functionalities, which of course could not
be done since
he was running a pure C++ program which has no knowledge of any python
interpreter.
Note that the above include is the only reference to pyublas, i.e. there
was no attempt
(yet) to create any numpy_vector array or anything in this program.
Again I apologize for my sketchiness in describing the issue and I may get
back later
to be more explicit.
However, can you let me know if your package is meant to be used
exclusively from
python? As I said in my last post, we write C++ code that is called from
other C++
code, or that may provide services to other clients, not necessarily python
apps.
If it is the case that pyublas is inextricably linked to a python
interpreter, then would
that mean that whenever we want to benefit from pyublas handle semantics
when calling
from python, we would have to write some kind of interface layer, callable
only from
python and which would call into pyublas agnostic C++ code? Am I seeing
this right?
Also, if satisfied with value semantics, then can we nevertheless expose
pure-ublas signed
C++ functionality to python without any reference to pyublas on the C++
side? (Actually,
I can try that out myself, but you probably know that anyway.)

PyUblas (at least in its current form) needs to call into the Numpy interface,
which--surprise--is only available if we're running inside a Python
interpreter. To call into the numpy interface, PyUblas uses this static
initializer:

namespace
{
static struct _pyublas_array_importer
{
_pyublas_array_importer()
{
import_array();
}
} _array_importer;
}

Now, import_array [http://is.gd/4wk1Q] doesn't exactly have the world's best
documentation on what it does when it fails, but "crash" is definitely a
possibility. At the cost of a fair bit of performance, this could be converted
to perform import_array() on first use, so if you're not using it, you're not
suffering from the issue. Or you could embed a Python interpeter in your
standalone executable, in which case Numpy would be available. Or you could
code around having to include pyublas/numpy.hpp (which causes the static
initializer to kick in) by making all your functions templated.

HTH,
Andreas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.tiker.net/pipermail/pyublas/attachments/20091022/d5d7ffa6/attachment.pgp>