[Numpy-discussion] Distutils: using different linker options for c++ and c code
David Cournapeau
david at ar.media.kyoto-u.ac.jp
Fri Apr 18 02:21:22 EDT 2008
Robert Kern wrote:
>
> Quite possibly. Can you run the segfaulting code in a debugger so we
> can try to isolate the actual cause? It is possible that we can patch
> it up to work with msvcr71.
I finally managed to do something, for reference:
- I hacked distutils to put -g everywhere (using the --debug in
distutils lead to nowhere for me: the debugging library is not ABI
compatible so just copying python25 to python25_d does not work, and I
can't rebuild python in debug mode since I don't have VS 2003)
- I rebuilt everything (scipy only)
- I used drmingw as the so called JIT debugger (registering it with
drmingw -i): now, when scipy.sparse crashes, I get into the code.
python.exe caused an Access Violation at location 66d571c1 in module
_bsr.pyd Reading from location 015d6000.
Registers:
eax=015d5fe8 ebx=00000006 ecx=00000002 edx=00000012 esi=00000006
edi=0000000a
eip=66d571c1 esp=0021c488 ebp=0021c4bc iopl=0 nv up ei ng nz ac
po cy
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000
efl=00000297
Call stack:
66D571C1 _bsr.pyd:66D571C1 void csr_binop_csr<int, short,
std::plus<short> >(int, int, int const*, int const*, short const*, int
const*, int const*, short const*, int*, int*, short*, std::plus<short>
const&) csr.h:663
...
nnz++;
}
> B_j = Bj[++B_pos];
}
}
...
66D472B0 _bsr.pyd:66D472B0 void bsr_binop_bsr<int, short,
std::plus<short> >(int, int, int, int, int const*, int const*, short
const*, int const*, int const*, short const*, int*, int*, short*,
std::plus<short> const&) bsr.h:550
...
}
> Cp[i+1] = nnz;
}
}
...
66D3934C _bsr.pyd:66D3934C void bsr_plus_bsr<int, short>(int, int,
int, int, int const*, int const*, short const*, int const*, int const*,
short const*, int*, int*, short*) bsr.h:580
...
I Cp[], I Cj[], T Cx[])
{
>
bsr_binop_bsr(n_row,n_col,R,C,Ap,Aj,Ax,Bp,Bj,Bx,Cp,Cj,Cx,std::plus<T>());
}
...
66D01087 _bsr.pyd:66D01087 _wrap_bsr_plus_bsr bsr_wrap.cxx:1226
...
SWIG_Py_Void(void)
{
> PyObject *none = Py_None;
Py_INCREF(none);
return none;
...
1E08E137 python25.dll:1E08E137 PyCFunction_Call
1E1E7A10 python25.dll:1E1E7A10 PyTuple_Type
So it *may* be unrelated to msvc runtime; maybe it just caused a problem
which has always been there. I will try to see if valgrind says anything
useful for sparsetools under linux.
David
More information about the NumPy-Discussion
mailing list