[SciPy-dev] crash with 'import scipy.linalg' and 'import scipy.io'

[John Pye]

Hi Robert

Thanks for the reply. It sounds like my guess about the global variables
in numpy was right then. Globals are bad.

Embedding python in this case was a necessary evil to do with the legacy
architecture: the place where the callbacks needed to be made was inside
a secondary DLL/SO that didn't have access to the SWIG wrapper layer. So
I needed to fire up embedded python and grab hooks to values (GUI
objects, for example) in the original interpreter via a global variable
mechanism. Globals are bad, again, but at least it didn't crash :-)

Perhaps the way I did this might be of interest. I used a hash table
function to register global variables used in one interpreter frame so
that they could be retrieved in the other frame. If numpy is creating
some variables that might be required in other frames, perhaps they
should be registered somewhere, if they can't be removed?

Cheers
JP

Robert Kern wrote:
> John Pye wrote:
>   
>> Hi Ravi
>>
>> Thanks for the reply, and I'm pleased to hear that you've had success
>> with what I'm trying to do. Did that backtrace mean anything to you?
>>
>> The only other place numpy is used in my code is in the highest-level,
>> which is a python GUI written on top of my SWIG-wrapped C library. The
>> latest thing is that I have attempted to make some python callbacks from
>> *plugins* in the low-level C code, which, being plugins, didn't have
>> access to all the SWIG wrappings. So numpy is being imported twice but
>> in different 'frames'. I bet that something scipy/numpy is assuming with
>> regard to global variables is what's falling over. Other modules have
>> imported OK: sys, io, subprocess. Just not scipy.io or scipy.linalg.
>>     
>
> Or anything else that uses numpy. numpy does not currently allow being imported
> from multiple interpreters in the same process because of those global
> variables. Unfortunately, those variables can't be trivially removed (although
> if you figure out a workaround, I would love to hear it).
>
> However, embedding a Python interpreter in a C extension to a Python program is
> probably not a good idea regardless, and I'm not entirely sure why you would
> need to do so.
>
>