Re: [Numpy-discussion] subclassing array in c
Sure. Check the memcheck tool of Valgrind:
http://valgrind.org/info/tools.html#memcheck
It is a really amazing tool.
Francesc
On Mar 8, 2012, at 11:00 PM, Christoph Gohle wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi again,
>
> I don't want to look as if I want other people do my work, so I would like to
> ask if there is a simple way of tracing memory leaks (without recompiling the
> python interpreter)?
>
> Cheers,
> Christoph
> Am 09.03.2012 um 01:22 schrieb Christoph Gohle:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Hi
>> Am 08.03.2012 um 20:39 schrieb Pauli Virtanen:
>>
>>> 08.03.2012 17:37, Christoph Gohle kirjoitti:
thanks for testing. I have now tried on different platforms. I get
all kinds of crashes on os x (now with numpy 1.6.1) and windows
with numpy 1.6.0. On Ubuntu with numpy 1.3.0 I get a hughe memory
leak...
Any hints would be welcome.
>>>
>>> The type object inherits `tp_alloc` from Numpy. This routine always
>>> allocates memory of size NPY_SIZEOF_PYARRAYOBJECT for the
>>> PyArrayObject. Therefore, the write to new->unit in your
>>> __array_finalize__ goes to unallocated memory.
>>>
>>> This is probably a bug in Numpy --- arrayobject.c:array_alloc should
>>> respect the size specified by the subtype.
>>>
>>> A workaround is probably to specify a suitable tp_alloc routine yourself:
>>>
>>> PyType_GenericAlloc,/* tp_alloc */
>>> unitArray_new, /* tp_new */
>>> _PyObject_Del /* tp_free */
>>>
>> OK, I did that. And I get no more segfaults as far as I can tell. But there
>> is still a memory leak:
>>
>> In [1]: import spampub
>>
>> In [2]: a=[spampub.UnitArray(i,{'s':i}) for i in xrange(10)]
>>
>> In [3]: del a
>>
>> after the last two statements, python uses ~60MB more memory than before.
>>
>> Thanks for your help
>> Christoph
>>> --
>>> Pauli Virtanen
>>>
>>> ___
>>> NumPy-Discussion mailing list
>>> NumPy-Discussion@scipy.org
>>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>>
>>
>> Christoph Gohle
>> - --
>> Max-Planck-Institut für Quantenoptik
>> Abteilung Quantenvielteilchensysteme
>> Hans-Kopfermann-Strasse 1
>> 85748 Garching
>>
>> christoph.go...@mpq.mpg.de
>> tel: +49 89 32905 283
>> fax: +49 89 32905 313
>>
>>
>>
>> -BEGIN PGP SIGNATURE-
>> Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
>>
>> iEYEARECAAYFAk9ZTVgACgkQLYu25rCEIztbcwCfcyeQ+FtKTOwFUGbleX/CrjPi
>> nZcAnj86kejcAO45YbX+I+rxhU9kq4PU
>> =KGdt
>> -END PGP SIGNATURE-
>> ___
>> NumPy-Discussion mailing list
>> NumPy-Discussion@scipy.org
>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
> Christoph Gohle
> - --
> Max-Planck-Institut für Quantenoptik
> Abteilung Quantenvielteilchensysteme
> Hans-Kopfermann-Strasse 1
> 85748 Garching
>
> christoph.go...@mpq.mpg.de
> tel: +49 89 32905 283
> fax: +49 89 32905 313
>
>
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
>
> iEYEARECAAYFAk9ZqnQACgkQLYu25rCEIzthWACgi0dYy2nh83w57Ho8emkvJZ8z
> KrkAnistJfaU29tzul8nrJBYsrdmksJk
> =Iyr4
> -END PGP SIGNATURE-
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
-- Francesc Alted
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] subclassing array in c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi again,
I don't want to look as if I want other people do my work, so I would like to
ask if there is a simple way of tracing memory leaks (without recompiling the
python interpreter)?
Cheers,
Christoph
Am 09.03.2012 um 01:22 schrieb Christoph Gohle:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi
> Am 08.03.2012 um 20:39 schrieb Pauli Virtanen:
>
>> 08.03.2012 17:37, Christoph Gohle kirjoitti:
>>> thanks for testing. I have now tried on different platforms. I get
>>> all kinds of crashes on os x (now with numpy 1.6.1) and windows
>>> with numpy 1.6.0. On Ubuntu with numpy 1.3.0 I get a hughe memory
>>> leak...
>>>
>>> Any hints would be welcome.
>>
>> The type object inherits `tp_alloc` from Numpy. This routine always
>> allocates memory of size NPY_SIZEOF_PYARRAYOBJECT for the
>> PyArrayObject. Therefore, the write to new->unit in your
>> __array_finalize__ goes to unallocated memory.
>>
>> This is probably a bug in Numpy --- arrayobject.c:array_alloc should
>> respect the size specified by the subtype.
>>
>> A workaround is probably to specify a suitable tp_alloc routine yourself:
>>
>> PyType_GenericAlloc,/* tp_alloc */
>> unitArray_new, /* tp_new */
>> _PyObject_Del /* tp_free */
>>
> OK, I did that. And I get no more segfaults as far as I can tell. But there
> is still a memory leak:
>
> In [1]: import spampub
>
> In [2]: a=[spampub.UnitArray(i,{'s':i}) for i in xrange(10)]
>
> In [3]: del a
>
> after the last two statements, python uses ~60MB more memory than before.
>
> Thanks for your help
> Christoph
>> --
>> Pauli Virtanen
>>
>> ___
>> NumPy-Discussion mailing list
>> NumPy-Discussion@scipy.org
>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
> Christoph Gohle
> - --
> Max-Planck-Institut für Quantenoptik
> Abteilung Quantenvielteilchensysteme
> Hans-Kopfermann-Strasse 1
> 85748 Garching
>
> christoph.go...@mpq.mpg.de
> tel: +49 89 32905 283
> fax: +49 89 32905 313
>
>
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
>
> iEYEARECAAYFAk9ZTVgACgkQLYu25rCEIztbcwCfcyeQ+FtKTOwFUGbleX/CrjPi
> nZcAnj86kejcAO45YbX+I+rxhU9kq4PU
> =KGdt
> -END PGP SIGNATURE-
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
Christoph Gohle
- --
Max-Planck-Institut für Quantenoptik
Abteilung Quantenvielteilchensysteme
Hans-Kopfermann-Strasse 1
85748 Garching
christoph.go...@mpq.mpg.de
tel: +49 89 32905 283
fax: +49 89 32905 313
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
iEYEARECAAYFAk9ZqnQACgkQLYu25rCEIzthWACgi0dYy2nh83w57Ho8emkvJZ8z
KrkAnistJfaU29tzul8nrJBYsrdmksJk
=Iyr4
-END PGP SIGNATURE-
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] subclassing array in c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi
Am 08.03.2012 um 20:39 schrieb Pauli Virtanen:
> 08.03.2012 17:37, Christoph Gohle kirjoitti:
>> thanks for testing. I have now tried on different platforms. I get
>> all kinds of crashes on os x (now with numpy 1.6.1) and windows
>> with numpy 1.6.0. On Ubuntu with numpy 1.3.0 I get a hughe memory
>> leak...
>>
>> Any hints would be welcome.
>
> The type object inherits `tp_alloc` from Numpy. This routine always
> allocates memory of size NPY_SIZEOF_PYARRAYOBJECT for the
> PyArrayObject. Therefore, the write to new->unit in your
> __array_finalize__ goes to unallocated memory.
>
> This is probably a bug in Numpy --- arrayobject.c:array_alloc should
> respect the size specified by the subtype.
>
> A workaround is probably to specify a suitable tp_alloc routine yourself:
>
> PyType_GenericAlloc,/* tp_alloc */
>unitArray_new, /* tp_new */
>_PyObject_Del /* tp_free */
>
OK, I did that. And I get no more segfaults as far as I can tell. But there is
still a memory leak:
In [1]: import spampub
In [2]: a=[spampub.UnitArray(i,{'s':i}) for i in xrange(10)]
In [3]: del a
after the last two statements, python uses ~60MB more memory than before.
Thanks for your help
Christoph
> --
> Pauli Virtanen
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
Christoph Gohle
- --
Max-Planck-Institut für Quantenoptik
Abteilung Quantenvielteilchensysteme
Hans-Kopfermann-Strasse 1
85748 Garching
christoph.go...@mpq.mpg.de
tel: +49 89 32905 283
fax: +49 89 32905 313
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
iEYEARECAAYFAk9ZTVgACgkQLYu25rCEIztbcwCfcyeQ+FtKTOwFUGbleX/CrjPi
nZcAnj86kejcAO45YbX+I+rxhU9kq4PU
=KGdt
-END PGP SIGNATURE-
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] More SPARC pain
Hi,
On Tue, Mar 6, 2012 at 8:07 PM, Matthew Brett wrote:
> Hi,
>
> I found this test caused a bus error on current trunk:
>
>
> import numpy as np
>
> from StringIO import StringIO as BytesIO
>
> from numpy.testing import assert_array_equal
>
>
> def test_2d_buf():
> dtt = np.complex64
> arr = np.arange(10, dtype=dtt)
> # 2D array
> arr2 = np.reshape(arr, (2, 5))
> # Fortran write followed by (C or F) read caused bus error
> data_str = arr2.tostring('F')
> data_back = np.ndarray(arr2.shape,
> arr2.dtype,
> buffer=data_str,
> order='F')
> assert_array_equal(arr2, data_back)
>
>
> gdb run gives ...
>
> test_me3.test_2d_buf ...
> Program received signal SIGBUS, Bus error.
> 0xf78f5458 in _aligned_strided_to_contig_size8 (
> dst=0xdc0e08
> "\313\313\313\313\313\313\313\313\313\313\313\313\313\313\313\313\313\313\313\313\313\313\313\313\313\313\313\313\313\313\313\313\313\313\313\313\313\313\313\313\313\313\313\313\313\313\313\313\313\313\313\313\313\313\313\313\313\313\313\313\313\313\313\313\313\313\313\313\313\313\313\313\313\313\313\313\313\313\313\313\373\373\373\373",
> dst_stride=8, src=0xcdfc44 "", src_stride=16, N=5,
> __NPY_UNUSED_TAGGEDsrc_itemsize=8,
> __NPY_UNUSED_TAGGEDdata=0x0) at
> numpy/core/src/multiarray/lowlevel_strided_loops.c.src:137
> 137 (*((@type@ *)dst)) = @swap@@elsize@(*((@type@ *)src));
>
> Debug log attached. Shall I make an issue?
http://projects.scipy.org/numpy/ticket/2076
Best,
Matthew
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Casting rules changed in trunk?
Hi,
On Wed, Mar 7, 2012 at 4:08 PM, Matthew Brett wrote:
> Hi,
>
> I noticed a casting change running the test suite on our image reader,
> nibabel:
> https://github.com/nipy/nibabel/blob/master/nibabel/tests/test_casting.py
>
> For this script:
>
>
> import numpy as np
>
> Adata = np.zeros((2,), dtype=np.uint8)
> Bdata = np.zeros((2,), dtype=np.int16)
> Bzero = np.int16(0)
> Bbig = np.int16(256)
>
> print np.__version__
> print 'Array add', (Adata + Bdata).dtype
> print 'Scalar 0 add', (Adata + Bzero).dtype
> print 'Scalar 256 add', (Adata + Bbig).dtype
>
>
> 1.4.1
> Array add int16
> Scalar 0 add uint8
> Scalar 256 add uint8
>
> 1.5.1
> Array add int16
> Scalar 0 add uint8
> Scalar 256 add uint8
>
> 1.6.1
> Array add int16
> Scalar 0 add uint8
> Scalar 256 add int16
>
> 1.7.0.dev-aae5b0a
> Array add int16
> Scalar 0 add uint8
> Scalar 256 add uint16
>
> I can understand the uint8 outputs from numpy < 1.6 - the rule being
> not to upcast for scalars.
>
> I can understand the int16 output from 1.6.1 on the basis that the
> value is outside uint8 range and therefore we might prefer a type that
> can handle values from both uint8 and int16.
>
> Was the current change intended? It has the following odd effect:
>
> In [5]: Adata + np.int16(257)
> Out[5]: array([257, 257], dtype=uint16)
>
> In [7]: Adata + np.int16(-257)
> Out[7]: array([-257, -257], dtype=int16)
>
> In [8]: Adata - np.int16(257)
> Out[8]: array([65279, 65279], dtype=uint16)
>
> but I guess you can argue that there are odd effects for other choices too,
In case it wasn't clear, this, in numpy 1.6.1:
In [2]: (np.zeros((2,), dtype=np.uint8) + np.int16(257)).dtype
Out[2]: dtype('int16')
changed to this in current trunk:
In [2]: (np.zeros((2,), dtype=np.uint8) + np.int16(257)).dtype
Out[2]: dtype('uint16')
which is different still in previous versions of numpy (e.g. 1.4.1):
In [2]: (np.zeros((2,), dtype=np.uint8) + np.int16(257)).dtype
Out[2]: dtype('uint8')
My impression had been that the plan was to avoid changes in the
casting rules if possible.
Was this change in trunk intentional? If not, I am happy to bisect,
Best,
Matthew
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] subclassing array in c
08.03.2012 17:37, Christoph Gohle kirjoitti: > thanks for testing. I have now tried on different platforms. I get > all kinds of crashes on os x (now with numpy 1.6.1) and windows > with numpy 1.6.0. On Ubuntu with numpy 1.3.0 I get a hughe memory > leak... > > Any hints would be welcome. The type object inherits `tp_alloc` from Numpy. This routine always allocates memory of size NPY_SIZEOF_PYARRAYOBJECT for the PyArrayObject. Therefore, the write to new->unit in your __array_finalize__ goes to unallocated memory. This is probably a bug in Numpy --- arrayobject.c:array_alloc should respect the size specified by the subtype. A workaround is probably to specify a suitable tp_alloc routine yourself: PyType_GenericAlloc,/* tp_alloc */ unitArray_new, /* tp_new */ _PyObject_Del /* tp_free */ -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] subclassing array in c
Dear Val,
thanks for testing. I have now tried on different platforms. I get all kinds of
crashes on os x (now with numpy 1.6.1) and windows with numpy 1.6.0. On Ubuntu
with numpy 1.3.0 I get a hughe memory leak...
Any hints would be welcome.
Thanks,
Christoph
Am 08.03.2012 um 09:08 schrieb Val Kalatsky:
> Hi Christoph,
>
> I've just tried
> a=[spampub.UnitArray(i,{'s':i}) for i in xrange(1000)]
> and everything looks fine on my side.
> Probably my test environment is too different to give comparable results:
>
> In [3]: call(["uname", "-a"])
> Linux ubuntu 2.6.35-22-generic #33-Ubuntu SMP Sun Sep 19 20:32:27 UTC 2010
> x86_64 GNU/Linux
> In [4]: np.__version__
> Out[4]: '1.5.1'
>
> I am afraid I will not be able to help testing it on super-nova versions of
> numpy.
> Cheers
> Val
>
>
> On Thu, Mar 8, 2012 at 1:49 AM, Christoph Gohle
> wrote:
> Dear Val,
>
> I agree that more detail is needed. Sorry for that it was late yesterday.
>
> I am running Python 2.6.1, numpy development branch
> (numpy-2.0.0.dev_20101104-py2.6-macosx-10.6-universal.egg). maybe I should
> switch to release?
>
> I compile with your setup.py using 'python setup.py build_ext -i' and run the
> commands below in ipython. As you can see, I don't get a crash for a single
> call to the constructor, consistent with your observation. And it looks like,
> one has to use dict in the unit to make it crash.
>
> Can you make sense out of that?
>
>
> In [1]: import spampub
>
> In [4]: spampub.UnitArray(1,{'s':1})
> Out[4]: UnitArray(1)
>
> In [6]: a=[spampub.UnitArray(i,{'s':i}) for i in xrange(1000)]
> Segmentation fault
>
> backtrace is the following:
>
> Exception Type: EXC_BAD_ACCESS (SIGSEGV)
> Exception Codes: KERN_INVALID_ADDRESS at 0x0021
> Crashed Thread: 0 Dispatch queue: com.apple.main-thread
>
> Thread 0 Crashed: Dispatch queue: com.apple.main-thread
> 0 org.python.python 0x0001000b0b8e PyObject_GC_Track +
> 1473
> 1 org.python.python 0x0001000b1255 _PyObject_GC_Malloc
> + 191
> 2 org.python.python 0x0001000b12d0 _PyObject_GC_New + 21
> 3 org.python.python 0x00010003a856 PyDict_New + 116
> 4 org.python.python 0x00010003a99c _PyDict_NewPresized
> + 24
> 5 org.python.python 0x0001000880cb PyEval_EvalFrameEx +
> 11033
> 6 org.python.python 0x00010008acce PyEval_EvalCodeEx +
> 1803
> 7 org.python.python 0x00010008735d PyEval_EvalFrameEx +
> 7595
> 8 org.python.python 0x00010008acce PyEval_EvalCodeEx +
> 1803
> 9 org.python.python 0x00010008935e PyEval_EvalFrameEx +
> 15788
> 10 org.python.python 0x00010008acce PyEval_EvalCodeEx +
> 1803
> 11 org.python.python 0x00010008935e PyEval_EvalFrameEx +
> 15788
> 12 org.python.python 0x0001000892e1 PyEval_EvalFrameEx +
> 15663
> 13 org.python.python 0x00010008acce PyEval_EvalCodeEx +
> 1803
> 14 org.python.python 0x00010008935e PyEval_EvalFrameEx +
> 15788
> 15 org.python.python 0x00010008acce PyEval_EvalCodeEx +
> 1803
> 16 org.python.python 0x00010008935e PyEval_EvalFrameEx +
> 15788
> 17 org.python.python 0x00010008acce PyEval_EvalCodeEx +
> 1803
> 18 org.python.python 0x00010008935e PyEval_EvalFrameEx +
> 15788
> 19 org.python.python 0x00010008acce PyEval_EvalCodeEx +
> 1803
> 20 org.python.python 0x00010008935e PyEval_EvalFrameEx +
> 15788
> 21 org.python.python 0x00010008acce PyEval_EvalCodeEx +
> 1803
> 22 org.python.python 0x00010008ad61 PyEval_EvalCode + 54
> 23 org.python.python 0x0001000a265a Py_CompileString + 78
> 24 org.python.python 0x0001000a2723 PyRun_FileExFlags +
> 150
> 25 org.python.python 0x0001000a423d
> PyRun_SimpleFileExFlags + 704
> 26 org.python.python 0x0001000b0286 Py_Main + 2718
> 27 org.python.python.app 0x00010e6c start + 52
>
> Am 08.03.2012 um 02:36 schrieb Val Kalatsky:
>
>>
>> Tried it on my Ubuntu 10.10 box, no problem:
>>
>> 1) Saved as spampub.c
>> 2) Compiled with (setup.py attached): python setup.py build_ext -i
>> 3) Tested from ipython:
>> In [1]: import spampub
>> In [2]: ua=spampub.UnitArray([0,1,2,3.0],'liter')
>> In [3]: ua
>> Out[3]: UnitArray([ 0., 1., 2., 3.])
>> In [4]: ua.unit
>> Out[4]: 'liter'
>>
>>
>> On Wed, Mar 7, 2012 at 7:15 PM, Val Kalatsky wrote:
>>
>> Seeing the backtrace would be helpful.
>> Can you do whatever leads to the segfault
>> from python run from gdb?
>> Val
>>
>>
>> On Wed, Mar 7, 2012 at 7:04 PM, Christoph Gohle
>> wrote:
>> -BEGIN PGP SIGNED MESS
Re: [Numpy-discussion] subclassing array in c
Hi Christoph,
I've just tried
a=[spampub.UnitArray(i,{'s':i}) for i in xrange(1000)]
and everything looks fine on my side.
Probably my test environment is too different to give comparable results:
In [3]: call(["uname", "-a"])
Linux ubuntu 2.6.35-22-generic #33-Ubuntu SMP Sun Sep 19 20:32:27 UTC 2010
x86_64 GNU/Linux
In [4]: np.__version__
Out[4]: '1.5.1'
I am afraid I will not be able to help testing it on super-nova versions of
numpy.
Cheers
Val
On Thu, Mar 8, 2012 at 1:49 AM, Christoph Gohle
wrote:
> Dear Val,
>
> I agree that more detail is needed. Sorry for that it was late yesterday.
>
> I am running Python 2.6.1, numpy development branch
> (numpy-2.0.0.dev_20101104-py2.6-macosx-10.6-universal.egg). maybe I should
> switch to release?
>
> I compile with your setup.py using 'python setup.py build_ext -i' and run
> the commands below in ipython. As you can see, I don't get a crash for a
> single call to the constructor, consistent with your observation. And it
> looks like, one has to use dict in the unit to make it crash.
>
> Can you make sense out of that?
>
>
> In [1]: import spampub
>
> In [4]: spampub.UnitArray(1,{'s':1})
> Out[4]: UnitArray(1)
>
> In [6]: a=[spampub.UnitArray(i,{'s':i}) for i in xrange(1000)]
> Segmentation fault
>
> backtrace is the following:
>
> Exception Type: EXC_BAD_ACCESS (SIGSEGV)
> Exception Codes: KERN_INVALID_ADDRESS at 0x0021
> Crashed Thread: 0 Dispatch queue: com.apple.main-thread
>
> Thread 0 Crashed: Dispatch queue: com.apple.main-thread
> 0 org.python.python 0x0001000b0b8e PyObject_GC_Track +
> 1473
> 1 org.python.python 0x0001000b1255 _PyObject_GC_Malloc
> + 191
> 2 org.python.python 0x0001000b12d0 _PyObject_GC_New + 21
> 3 org.python.python 0x00010003a856 PyDict_New + 116
> 4 org.python.python 0x00010003a99c _PyDict_NewPresized
> + 24
> 5 org.python.python 0x0001000880cb PyEval_EvalFrameEx +
> 11033
> 6 org.python.python 0x00010008acce PyEval_EvalCodeEx +
> 1803
> 7 org.python.python 0x00010008735d PyEval_EvalFrameEx +
> 7595
> 8 org.python.python 0x00010008acce PyEval_EvalCodeEx +
> 1803
> 9 org.python.python 0x00010008935e PyEval_EvalFrameEx +
> 15788
> 10 org.python.python 0x00010008acce PyEval_EvalCodeEx +
> 1803
> 11 org.python.python 0x00010008935e PyEval_EvalFrameEx +
> 15788
> 12 org.python.python 0x0001000892e1 PyEval_EvalFrameEx +
> 15663
> 13 org.python.python 0x00010008acce PyEval_EvalCodeEx +
> 1803
> 14 org.python.python 0x00010008935e PyEval_EvalFrameEx +
> 15788
> 15 org.python.python 0x00010008acce PyEval_EvalCodeEx +
> 1803
> 16 org.python.python 0x00010008935e PyEval_EvalFrameEx +
> 15788
> 17 org.python.python 0x00010008acce PyEval_EvalCodeEx +
> 1803
> 18 org.python.python 0x00010008935e PyEval_EvalFrameEx +
> 15788
> 19 org.python.python 0x00010008acce PyEval_EvalCodeEx +
> 1803
> 20 org.python.python 0x00010008935e PyEval_EvalFrameEx +
> 15788
> 21 org.python.python 0x00010008acce PyEval_EvalCodeEx +
> 1803
> 22 org.python.python 0x00010008ad61 PyEval_EvalCode + 54
> 23 org.python.python 0x0001000a265a Py_CompileString + 78
> 24 org.python.python 0x0001000a2723 PyRun_FileExFlags +
> 150
> 25 org.python.python 0x0001000a423d
> PyRun_SimpleFileExFlags + 704
> 26 org.python.python 0x0001000b0286 Py_Main + 2718
> 27 org.python.python.app 0x00010e6c start + 52
>
> Am 08.03.2012 um 02:36 schrieb Val Kalatsky:
>
>
> Tried it on my Ubuntu 10.10 box, no problem:
>
> 1) Saved as spampub.c
> 2) Compiled with (setup.py attached): python setup.py build_ext -i
> 3) Tested from ipython:
> In [1]: import spampub
> In [2]: ua=spampub.UnitArray([0,1,2,3.0],'liter')
> In [3]: ua
> Out[3]: UnitArray([ 0., 1., 2., 3.])
> In [4]: ua.unit
> Out[4]: 'liter'
>
>
> On Wed, Mar 7, 2012 at 7:15 PM, Val Kalatsky wrote:
>
>>
>> Seeing the backtrace would be helpful.
>> Can you do whatever leads to the segfault
>> from python run from gdb?
>> Val
>>
>>
>> On Wed, Mar 7, 2012 at 7:04 PM, Christoph Gohle <
>> christoph.go...@mpq.mpg.de> wrote:
>>
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA1
>>>
>>> Hi,
>>>
>>> I have been struggeling for quite some time now. Desperate as I am, now
>>> I need help.
>>>
>>> I was trying to subclass ndarrays in a c extension (see code below) and
>>> do constantly get segfaults. I have been checking my INCREF and DECREF
>>> stuff up and down but can't find the error. Probably I got something
>>> completely wrong... anybody able to help?
>>>
>>> Thanks,
>>> Christoph
>>> - -
>>> #include
>>> #include
>>>
>>> #inc
