Issue 1:
Original ticket http://projects.scipy.org/numpy/ticket/881 on 2008-08-07 by trac user mgogoulos@..., assigned to @cournape.

numpy.object0 and numpy.object result in segmentation fault, see the following:

$ gdb python

...

(gdb) run -c "import numpy; obj = numpy.object0()"

Starting program: /usr/bin/python -c "import numpy; obj = numpy.object0()"

...

[New Thread 0xb7d498c0 (LWP 17024)]

Program received signal SIGSEGV, Segmentation fault.

[Switching to Thread 0xb7d498c0 (LWP 17024)]

object_arrtype_new (type=0xb7c7d1c0, args=0xb7d0902c, kwds=0x0) at numpy/core/src/scalartypes.inc.src:1977

1977 Py_INCREF(((PyObject *)dest));

Tested on versions '1.0.4' and 1.1.1 with scipy 0.6.0, on Ubuntu hardy (python 2.5.2)

Best regards,

Markos Gogoulos

Issue 2:
Original ticket http://projects.scipy.org/numpy/ticket/816 on 2008-06-09 by @pv, assigned to unknown.

The following code causes a segmentation fault:

import numpy as np
print np.__version__
np.object_(3)

The reason apparently is (see the Valgrind trace below) that the object_ constructor expects a memory address as its parameter. This functionality probably shouldn't be user-visible.

Valgrind trace:

$ valgrind --suppressions=.valgrind/valgrind-python.supp python -c 'import numpy; print numpy.__version__; numpy.object_(3)'
...
1.1.0
==23495==
==23495== Invalid read of size 4
==23495== at 0x4A6830F: object_arrtype_new (scalartypes.inc.src:1877)
==23495== by 0x809EDCC: type_call (typeobject.c:422)
==23495== by 0x805CB36: PyObject_Call (abstract.c:1861)
==23495== by 0x80C7986: PyEval_EvalFrameEx (ceval.c:3784)
==23495== by 0x80CB0D6: PyEval_EvalCodeEx (ceval.c:2836)
==23495== by 0x80CB226: PyEval_EvalCode (ceval.c:494)
==23495== by 0x80EB474: PyRun_StringFlags (pythonrun.c:1273)
==23495== by 0x80EB534: PyRun_SimpleStringFlags (pythonrun.c:900)
==23495== by 0x8058C80: Py_Main (main.c:512)
==23495== by 0x80587F1: main (python.c:23)
==23495== Address 0x3 is not stack'd, malloc'd or (recently) free'd
==23495==
==23495== Process terminating with default action of signal 11 (SIGSEGV)
==23495== Access not within mapped region at address 0x3
==23495== at 0x4A6830F: object_arrtype_new (scalartypes.inc.src:1877)
==23495== by 0x809EDCC: type_call (typeobject.c:422)
==23495== by 0x805CB36: PyObject_Call (abstract.c:1861)
==23495== by 0x80C7986: PyEval_EvalFrameEx (ceval.c:3784)
==23495== by 0x80CB0D6: PyEval_EvalCodeEx (ceval.c:2836)
==23495== by 0x80CB226: PyEval_EvalCode (ceval.c:494)
==23495== by 0x80EB474: PyRun_StringFlags (pythonrun.c:1273)
==23495== by 0x80EB534: PyRun_SimpleStringFlags (pythonrun.c:900)
==23495== by 0x8058C80: Py_Main (main.c:512)
==23495== by 0x80587F1: main (python.c:23)
==23495==
==23495== ERROR SUMMARY: 34 errors from 9 contexts (suppressed: 1194 from 7)
==23495== malloc/free: in use at exit: 4,800,420 bytes in 4,902 blocks.
==23495== malloc/free: 104,174 allocs, 99,272 frees, 48,061,410 bytes allocated.
==23495== For counts of detected errors, rerun with: -v
==23495== searching for pointers to 4,902 not-freed blocks.
==23495== checked 6,128,912 bytes.
==23495==
==23495== LEAK SUMMARY:
==23495== definitely lost: 0 bytes in 0 blocks.
==23495== possibly lost: 110,244 bytes in 210 blocks.
==23495== still reachable: 4,690,176 bytes in 4,692 blocks.
==23495== suppressed: 0 bytes in 0 blocks.
==23495== Rerun with --leak-check=full to see details of leaked memory.
Segmentation fault