Re: [Numpy-discussion] Segmentation fault during tests with Python 2.7.2 on Debian 6?
Charles R Harris charlesr.harris at gmail.com writes: On Thu, Apr 12, 2012 at 8:13 PM, Charles R Harris charlesr.harris at gmail.com wrote: On Thu, Apr 12, 2012 at 7:41 PM, Charles R Harris charlesr.harris at gmail.com wrote: On Thu, Apr 12, 2012 at 2:05 AM, Chris Ball ceball at gmail.com wrote: Hi, I'm trying out various continuous integration options, so I happen to be testing NumPy on several platforms that I don't normally use. Recently, I've been getting a segmentation fault on Debian 6 (with Python 2.7.2): Linux debian6-amd64 2.6.32-5-amd64 #1 SMP Thu Mar 22 17:26:33 UTC 2012 x86_64 GNU/Linux (Debian GNU/Linux 6.0 \n \l) ... Segmentation fault is buried in console output of Jenkins:https:// jenkins.shiningpanda.com/scipy/job/NumPy/PYTHON=CPython-2.7/6/console The previous build was ok:https://jenkins.shiningpanda.com/scipy/job/NumPy/ PYTHON=CPython-2.7/5/console Changes that Jenkins claims are responsible:https://jenkins.shiningpanda.com/ scipy/job/NumPy/PYTHON=CPython-2.7/6/ changes#detail0 It seems that python2.7 is far, far, too recent to be part of Debian 6. I mean, finding python 2.7 in recent Debian stable would be like finding an atomic cannon in a 1'st dynasty Egyptian tomb. So it is in testing, but for replication I like to know where you got it. Python 2.7 from Debian testing works fine here. But ActiveState python (ucs2) segfaults with a = np.array(['0123456789'], 'U') aSegmentation faultThe string needs to be long for this to show.Chuck Sorry for the delay. I'll let you know about that as soon as I can (I didn't set up the machine, and although I can get ssh access, it's not straightforward). Chris ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Segmentation fault during tests with Python 2.7.2 on Debian 6?
On Mon, Apr 16, 2012 at 5:16 PM, Chris Ball ceb...@gmail.com wrote: Charles R Harris charlesr.harris at gmail.com writes: On Thu, Apr 12, 2012 at 8:13 PM, Charles R Harris charlesr.harris at gmail.com wrote: On Thu, Apr 12, 2012 at 7:41 PM, Charles R Harris charlesr.harris at gmail.com wrote: On Thu, Apr 12, 2012 at 2:05 AM, Chris Ball ceball at gmail.com wrote: Hi, I'm trying out various continuous integration options, so I happen to be testing NumPy on several platforms that I don't normally use. Recently, I've been getting a segmentation fault on Debian 6 (with Python 2.7.2): Linux debian6-amd64 2.6.32-5-amd64 #1 SMP Thu Mar 22 17:26:33 UTC 2012 x86_64 GNU/Linux (Debian GNU/Linux 6.0 \n \l) ... Segmentation fault is buried in console output of Jenkins:https:// jenkins.shiningpanda.com/scipy/job/NumPy/PYTHON=CPython-2.7/6/console The previous build was ok: https://jenkins.shiningpanda.com/scipy/job/NumPy/ PYTHON=CPython-2.7/5/console Changes that Jenkins claims are responsible: https://jenkins.shiningpanda.com/ scipy/job/NumPy/PYTHON=CPython-2.7/6/ changes#detail0 It seems that python2.7 is far, far, too recent to be part of Debian 6. I mean, finding python 2.7 in recent Debian stable would be like finding an atomic cannon in a 1'st dynasty Egyptian tomb. So it is in testing, but for replication I like to know where you got it. Python 2.7 from Debian testing works fine here. But ActiveState python (ucs2) segfaults with a = np.array(['0123456789'], 'U') aSegmentation faultThe string needs to be long for this to show.Chuck Sorry for the delay. I'll let you know about that as soon as I can (I didn't set up the machine, and although I can get ssh access, it's not straightforward). Don't worry about it yet, I'm working on a fix. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Segmentation fault during tests with Python 2.7.2 on Debian 6?
On 4/12/12 8:41 PM, Charles R Harris wrote:
It seems that python2.7 is far, far, too recent to be part of Debian
6. I mean, finding python 2.7 in recent Debian stable would be like
finding an atomic cannon in a 1'st dynasty Egyptian tomb. So it is in
testing, but for replication I like to know where you got it.
Chuck
Just to add a data point, Maggie built python 2.7.2 on Debian 32 and 64
bit VMs yesterday and saw the same error. Interestingly, it segfaults in
different places:
32 bit
Program received signal SIGSEGV, Segmentation fault.
PyObject_Malloc (nbytes=48) at Objects/obmalloc.c:788
788if ((pool-freeblock = *(block **)bp) != NULL) {
#0 PyObject_Malloc (nbytes=48) at Objects/obmalloc.c:788
#1 0x08095ad5 in _PyObject_New (tp=0xb7b80180) at Objects/object.c:244
#2 0xb7af433f in PyArray_DescrNew (type_num=18)
at numpy/core/src/multiarray/descriptor.c:1457
#3 PyArray_DescrNewFromType (type_num=18)
at numpy/core/src/multiarray/descriptor.c:1106
#4 0xb7b1631c in PyArray_DTypeFromObjectHelper (obj=value optimized out,
maxdims=value optimized out, out_contains_na=0xbfffbae0,
out_dtype=0xbfffbae8, string_type=18)
at numpy/core/src/multiarray/common.c:259
64 bit
Program received signal SIGSEGV, Segmentation fault.
PyType_IsSubtype (a=0x2d00330030002d, b=0x76624b20) at
Objects/typeobject.c:1132
1132if (!(a-tp_flags Py_TPFLAGS_HAVE_CLASS))
(gdb) print a
$1 = (PyTypeObject *) 0x2d00330030002d
#0 PyType_IsSubtype (a=0x2d00330030002d, b=0x76624b20) at
Objects/typeobject.c:1132
#1 0x7639b8ad in STRING_setitem (op=0x134c930, ov=0x154f630 ,
ap=0x144f1d0)
at numpy/core/src/multiarray/arraytypes.c.src:476
#2 0x7639d466 in UNICODE_to_STRING (ip=0xf00 2,
op=0x154f630 , n=value optimized out,
aip=0x14fb5c0, aop=0x144f1d0) at
numpy/core/src/multiarray/arraytypes.c.src:1378
#3 0x762fa27f in _strided_to_strided_contig_align_wrap (dst=0x1
Address 0x1 out of bounds,
dst_stride=value optimized out, src=0x7fff9c40 \003,
src_stride=value optimized out,
N=140737488329280, src_itemsize=40, data=0x154f5c0) at
numpy/core/src/multiarray/dtype_transfer.c:354
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Segmentation fault during tests with Python 2.7.2 on Debian 6?
On Thu, Apr 12, 2012 at 2:05 AM, Chris Ball ceb...@gmail.com wrote: Hi, I'm trying out various continuous integration options, so I happen to be testing NumPy on several platforms that I don't normally use. Recently, I've been getting a segmentation fault on Debian 6 (with Python 2.7.2): Linux debian6-amd64 2.6.32-5-amd64 #1 SMP Thu Mar 22 17:26:33 UTC 2012 x86_64 GNU/Linux (Debian GNU/Linux 6.0 \n \l) nosetests --verbose /home/slave/tmp/numpy/numpy/random/__init__.py:91: RuntimeWarning: numpy.ndarray size changed, may indicate binary incompatibility from mtrand import * test_api.test_fastCopyAndTranspose ... ok test_api.test_array_astype ... ok test_api.test_copyto_fromscalar ... ok test_api.test_copyto ... ok test_api.test_copyto_maskna ... ok test_api.test_copy_order ... ok Basic test of array2string. ... ok Test custom format function for each element in array. ... ok This should only apply to 0-D arrays. See #1218. ... ok test_arrayprint.TestArrayRepr.test_nan_inf ... ok test_str (test_arrayprint.TestComplexArray) ... ok test_arrayprint.TestPrintOptions.test_basic ... ok test_arrayprint.TestPrintOptions.test_formatter ... ok test_arrayprint.TestPrintOptions.test_formatter_reset ... ok Ticket 844. ... ok test_blasdot.test_blasdot_used ... SKIP: Skipping test: test_blasdot_used Numpy is not compiled with _dotblas test_blasdot.test_dot_2args ... ok test_blasdot.test_dot_3args ... ok test_blasdot.test_dot_3args_errors ... ok test_creation_overflow (test_datetime.TestDateTime) ... ok test_datetime_add (test_datetime.TestDateTime) ... ok test_datetime_arange (test_datetime.TestDateTime) ... ok test_datetime_array_find_type (test_datetime.TestDateTime) ... ok test_datetime_array_str (test_datetime.TestDateTime) ... ok test_datetime_as_string (test_datetime.TestDateTime) ... ok test_datetime_as_string_timezone (test_datetime.TestDateTime) ... /home/slave/ tmp/numpy/numpy/core/tests/test_datetime.py:1319: UserWarning: pytz not found, pytz compatibility tests skipped warnings.warn(pytz not found, pytz compatibility tests skipped) ok test_datetime_busday_holidays_count (test_datetime.TestDateTime) ... ok test_datetime_busday_holidays_offset (test_datetime.TestDateTime) ... ok test_datetime_busday_offset (test_datetime.TestDateTime) ... ok test_datetime_busdaycalendar (test_datetime.TestDateTime) ... ok test_datetime_casting_rules (test_datetime.TestDateTime) ... ok test_datetime_divide (test_datetime.TestDateTime) ... ok test_datetime_dtype_creation (test_datetime.TestDateTime) ... ok test_datetime_is_busday (test_datetime.TestDateTime) ... ok test_datetime_like (test_datetime.TestDateTime) ... ok test_datetime_maximum_reduce (test_datetime.TestDateTime) ... ok test_datetime_minmax (test_datetime.TestDateTime) ... ok test_datetime_multiply (test_datetime.TestDateTime) ... ok test_datetime_nat_casting (test_datetime.TestDateTime) ... ok test_datetime_scalar_construction (test_datetime.TestDateTime) ... ok test_datetime_string_conversion (test_datetime.TestDateTime) ... ERROR test_datetime_subtract (test_datetime.TestDateTime) ... Segmentation fault I don't see this here, also on AMD x64_86 and Python 2.7. I suspect different unicode sizes leading to different code paths, or possibly the need for a clean install. Grr, now I've got to install debian somewhere... snip Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Segmentation fault during tests with Python 2.7.2 on Debian 6?
On Thu, Apr 12, 2012 at 2:05 AM, Chris Ball ceb...@gmail.com wrote: Hi, I'm trying out various continuous integration options, so I happen to be testing NumPy on several platforms that I don't normally use. Recently, I've been getting a segmentation fault on Debian 6 (with Python 2.7.2): Linux debian6-amd64 2.6.32-5-amd64 #1 SMP Thu Mar 22 17:26:33 UTC 2012 x86_64 GNU/Linux (Debian GNU/Linux 6.0 \n \l) nosetests --verbose /home/slave/tmp/numpy/numpy/random/__init__.py:91: RuntimeWarning: numpy.ndarray size changed, may indicate binary incompatibility from mtrand import * test_api.test_fastCopyAndTranspose ... ok test_api.test_array_astype ... ok test_api.test_copyto_fromscalar ... ok test_api.test_copyto ... ok test_api.test_copyto_maskna ... ok test_api.test_copy_order ... ok Basic test of array2string. ... ok Test custom format function for each element in array. ... ok This should only apply to 0-D arrays. See #1218. ... ok test_arrayprint.TestArrayRepr.test_nan_inf ... ok test_str (test_arrayprint.TestComplexArray) ... ok test_arrayprint.TestPrintOptions.test_basic ... ok test_arrayprint.TestPrintOptions.test_formatter ... ok test_arrayprint.TestPrintOptions.test_formatter_reset ... ok Ticket 844. ... ok test_blasdot.test_blasdot_used ... SKIP: Skipping test: test_blasdot_used Numpy is not compiled with _dotblas test_blasdot.test_dot_2args ... ok test_blasdot.test_dot_3args ... ok test_blasdot.test_dot_3args_errors ... ok test_creation_overflow (test_datetime.TestDateTime) ... ok test_datetime_add (test_datetime.TestDateTime) ... ok test_datetime_arange (test_datetime.TestDateTime) ... ok test_datetime_array_find_type (test_datetime.TestDateTime) ... ok test_datetime_array_str (test_datetime.TestDateTime) ... ok test_datetime_as_string (test_datetime.TestDateTime) ... ok test_datetime_as_string_timezone (test_datetime.TestDateTime) ... /home/slave/ tmp/numpy/numpy/core/tests/test_datetime.py:1319: UserWarning: pytz not found, pytz compatibility tests skipped warnings.warn(pytz not found, pytz compatibility tests skipped) ok test_datetime_busday_holidays_count (test_datetime.TestDateTime) ... ok test_datetime_busday_holidays_offset (test_datetime.TestDateTime) ... ok test_datetime_busday_offset (test_datetime.TestDateTime) ... ok test_datetime_busdaycalendar (test_datetime.TestDateTime) ... ok test_datetime_casting_rules (test_datetime.TestDateTime) ... ok test_datetime_divide (test_datetime.TestDateTime) ... ok test_datetime_dtype_creation (test_datetime.TestDateTime) ... ok test_datetime_is_busday (test_datetime.TestDateTime) ... ok test_datetime_like (test_datetime.TestDateTime) ... ok test_datetime_maximum_reduce (test_datetime.TestDateTime) ... ok test_datetime_minmax (test_datetime.TestDateTime) ... ok test_datetime_multiply (test_datetime.TestDateTime) ... ok test_datetime_nat_casting (test_datetime.TestDateTime) ... ok test_datetime_scalar_construction (test_datetime.TestDateTime) ... ok test_datetime_string_conversion (test_datetime.TestDateTime) ... ERROR test_datetime_subtract (test_datetime.TestDateTime) ... Segmentation fault With Python 2.6 there doesn't seem to be a problem on the same machine. Unfortunately, I haven't had time to investigate (I don't have Debian 6 to use myself, and I just started a job that doesn't involve any Python...). However, according to the Jenkins instance on ShiningPanda.com, the problem began with these changes: BUG: ticket #1578, Fix python-debug warning for python = 2.7. STY: Small style fixes. For now, that's all I can say; I haven't manually verified the problem myself (that it exists, or that it truly started after the changes above). I hope to be able to investigate further at the weekend, but I thought I'd post to the list now in case someone else can verify the problem. Chris Segmentation fault is buried in console output of Jenkins: https://jenkins.shiningpanda.com/scipy/job/NumPy/PYTHON=CPython-2.7/6/console The previous build was ok: https://jenkins.shiningpanda.com/scipy/job/NumPy/PYTHON=CPython-2.7/5/console Changes that Jenkins claims are responsible: https://jenkins.shiningpanda.com/scipy/job/NumPy/PYTHON=CPython-2.7/6/ changes#detail0 It seems that python2.7 is far, far, too recent to be part of Debian 6. I mean, finding python 2.7 in recent Debian stable would be like finding an atomic cannon in a 1'st dynasty Egyptian tomb. So it is in testing, but for replication I like to know where you got it. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Segmentation fault during tests with Python 2.7.2 on Debian 6?
On Thu, Apr 12, 2012 at 7:41 PM, Charles R Harris charlesr.har...@gmail.com wrote: On Thu, Apr 12, 2012 at 2:05 AM, Chris Ball ceb...@gmail.com wrote: Hi, I'm trying out various continuous integration options, so I happen to be testing NumPy on several platforms that I don't normally use. Recently, I've been getting a segmentation fault on Debian 6 (with Python 2.7.2): Linux debian6-amd64 2.6.32-5-amd64 #1 SMP Thu Mar 22 17:26:33 UTC 2012 x86_64 GNU/Linux (Debian GNU/Linux 6.0 \n \l) nosetests --verbose /home/slave/tmp/numpy/numpy/random/__init__.py:91: RuntimeWarning: numpy.ndarray size changed, may indicate binary incompatibility from mtrand import * test_api.test_fastCopyAndTranspose ... ok test_api.test_array_astype ... ok test_api.test_copyto_fromscalar ... ok test_api.test_copyto ... ok test_api.test_copyto_maskna ... ok test_api.test_copy_order ... ok Basic test of array2string. ... ok Test custom format function for each element in array. ... ok This should only apply to 0-D arrays. See #1218. ... ok test_arrayprint.TestArrayRepr.test_nan_inf ... ok test_str (test_arrayprint.TestComplexArray) ... ok test_arrayprint.TestPrintOptions.test_basic ... ok test_arrayprint.TestPrintOptions.test_formatter ... ok test_arrayprint.TestPrintOptions.test_formatter_reset ... ok Ticket 844. ... ok test_blasdot.test_blasdot_used ... SKIP: Skipping test: test_blasdot_used Numpy is not compiled with _dotblas test_blasdot.test_dot_2args ... ok test_blasdot.test_dot_3args ... ok test_blasdot.test_dot_3args_errors ... ok test_creation_overflow (test_datetime.TestDateTime) ... ok test_datetime_add (test_datetime.TestDateTime) ... ok test_datetime_arange (test_datetime.TestDateTime) ... ok test_datetime_array_find_type (test_datetime.TestDateTime) ... ok test_datetime_array_str (test_datetime.TestDateTime) ... ok test_datetime_as_string (test_datetime.TestDateTime) ... ok test_datetime_as_string_timezone (test_datetime.TestDateTime) ... /home/slave/ tmp/numpy/numpy/core/tests/test_datetime.py:1319: UserWarning: pytz not found, pytz compatibility tests skipped warnings.warn(pytz not found, pytz compatibility tests skipped) ok test_datetime_busday_holidays_count (test_datetime.TestDateTime) ... ok test_datetime_busday_holidays_offset (test_datetime.TestDateTime) ... ok test_datetime_busday_offset (test_datetime.TestDateTime) ... ok test_datetime_busdaycalendar (test_datetime.TestDateTime) ... ok test_datetime_casting_rules (test_datetime.TestDateTime) ... ok test_datetime_divide (test_datetime.TestDateTime) ... ok test_datetime_dtype_creation (test_datetime.TestDateTime) ... ok test_datetime_is_busday (test_datetime.TestDateTime) ... ok test_datetime_like (test_datetime.TestDateTime) ... ok test_datetime_maximum_reduce (test_datetime.TestDateTime) ... ok test_datetime_minmax (test_datetime.TestDateTime) ... ok test_datetime_multiply (test_datetime.TestDateTime) ... ok test_datetime_nat_casting (test_datetime.TestDateTime) ... ok test_datetime_scalar_construction (test_datetime.TestDateTime) ... ok test_datetime_string_conversion (test_datetime.TestDateTime) ... ERROR test_datetime_subtract (test_datetime.TestDateTime) ... Segmentation fault With Python 2.6 there doesn't seem to be a problem on the same machine. Unfortunately, I haven't had time to investigate (I don't have Debian 6 to use myself, and I just started a job that doesn't involve any Python...). However, according to the Jenkins instance on ShiningPanda.com, the problem began with these changes: BUG: ticket #1578, Fix python-debug warning for python = 2.7. STY: Small style fixes. For now, that's all I can say; I haven't manually verified the problem myself (that it exists, or that it truly started after the changes above). I hope to be able to investigate further at the weekend, but I thought I'd post to the list now in case someone else can verify the problem. Chris Segmentation fault is buried in console output of Jenkins: https://jenkins.shiningpanda.com/scipy/job/NumPy/PYTHON=CPython-2.7/6/console The previous build was ok: https://jenkins.shiningpanda.com/scipy/job/NumPy/PYTHON=CPython-2.7/5/console Changes that Jenkins claims are responsible: https://jenkins.shiningpanda.com/scipy/job/NumPy/PYTHON=CPython-2.7/6/ changes#detail0 It seems that python2.7 is far, far, too recent to be part of Debian 6. I mean, finding python 2.7 in recent Debian stable would be like finding an atomic cannon in a 1'st dynasty Egyptian tomb. So it is in testing, but for replication I like to know where you got it. Python 2.7 from Debian testing works fine here. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Segmentation fault during tests with Python 2.7.2 on Debian 6?
On Thu, Apr 12, 2012 at 8:13 PM, Charles R Harris charlesr.har...@gmail.com wrote: On Thu, Apr 12, 2012 at 7:41 PM, Charles R Harris charlesr.har...@gmail.com wrote: On Thu, Apr 12, 2012 at 2:05 AM, Chris Ball ceb...@gmail.com wrote: Hi, I'm trying out various continuous integration options, so I happen to be testing NumPy on several platforms that I don't normally use. Recently, I've been getting a segmentation fault on Debian 6 (with Python 2.7.2): Linux debian6-amd64 2.6.32-5-amd64 #1 SMP Thu Mar 22 17:26:33 UTC 2012 x86_64 GNU/Linux (Debian GNU/Linux 6.0 \n \l) nosetests --verbose /home/slave/tmp/numpy/numpy/random/__init__.py:91: RuntimeWarning: numpy.ndarray size changed, may indicate binary incompatibility from mtrand import * test_api.test_fastCopyAndTranspose ... ok test_api.test_array_astype ... ok test_api.test_copyto_fromscalar ... ok test_api.test_copyto ... ok test_api.test_copyto_maskna ... ok test_api.test_copy_order ... ok Basic test of array2string. ... ok Test custom format function for each element in array. ... ok This should only apply to 0-D arrays. See #1218. ... ok test_arrayprint.TestArrayRepr.test_nan_inf ... ok test_str (test_arrayprint.TestComplexArray) ... ok test_arrayprint.TestPrintOptions.test_basic ... ok test_arrayprint.TestPrintOptions.test_formatter ... ok test_arrayprint.TestPrintOptions.test_formatter_reset ... ok Ticket 844. ... ok test_blasdot.test_blasdot_used ... SKIP: Skipping test: test_blasdot_used Numpy is not compiled with _dotblas test_blasdot.test_dot_2args ... ok test_blasdot.test_dot_3args ... ok test_blasdot.test_dot_3args_errors ... ok test_creation_overflow (test_datetime.TestDateTime) ... ok test_datetime_add (test_datetime.TestDateTime) ... ok test_datetime_arange (test_datetime.TestDateTime) ... ok test_datetime_array_find_type (test_datetime.TestDateTime) ... ok test_datetime_array_str (test_datetime.TestDateTime) ... ok test_datetime_as_string (test_datetime.TestDateTime) ... ok test_datetime_as_string_timezone (test_datetime.TestDateTime) ... /home/slave/ tmp/numpy/numpy/core/tests/test_datetime.py:1319: UserWarning: pytz not found, pytz compatibility tests skipped warnings.warn(pytz not found, pytz compatibility tests skipped) ok test_datetime_busday_holidays_count (test_datetime.TestDateTime) ... ok test_datetime_busday_holidays_offset (test_datetime.TestDateTime) ... ok test_datetime_busday_offset (test_datetime.TestDateTime) ... ok test_datetime_busdaycalendar (test_datetime.TestDateTime) ... ok test_datetime_casting_rules (test_datetime.TestDateTime) ... ok test_datetime_divide (test_datetime.TestDateTime) ... ok test_datetime_dtype_creation (test_datetime.TestDateTime) ... ok test_datetime_is_busday (test_datetime.TestDateTime) ... ok test_datetime_like (test_datetime.TestDateTime) ... ok test_datetime_maximum_reduce (test_datetime.TestDateTime) ... ok test_datetime_minmax (test_datetime.TestDateTime) ... ok test_datetime_multiply (test_datetime.TestDateTime) ... ok test_datetime_nat_casting (test_datetime.TestDateTime) ... ok test_datetime_scalar_construction (test_datetime.TestDateTime) ... ok test_datetime_string_conversion (test_datetime.TestDateTime) ... ERROR test_datetime_subtract (test_datetime.TestDateTime) ... Segmentation fault With Python 2.6 there doesn't seem to be a problem on the same machine. Unfortunately, I haven't had time to investigate (I don't have Debian 6 to use myself, and I just started a job that doesn't involve any Python...). However, according to the Jenkins instance on ShiningPanda.com, the problem began with these changes: BUG: ticket #1578, Fix python-debug warning for python = 2.7. STY: Small style fixes. For now, that's all I can say; I haven't manually verified the problem myself (that it exists, or that it truly started after the changes above). I hope to be able to investigate further at the weekend, but I thought I'd post to the list now in case someone else can verify the problem. Chris Segmentation fault is buried in console output of Jenkins: https://jenkins.shiningpanda.com/scipy/job/NumPy/PYTHON=CPython-2.7/6/console The previous build was ok: https://jenkins.shiningpanda.com/scipy/job/NumPy/PYTHON=CPython-2.7/5/console Changes that Jenkins claims are responsible: https://jenkins.shiningpanda.com/scipy/job/NumPy/PYTHON=CPython-2.7/6/ changes#detail0 It seems that python2.7 is far, far, too recent to be part of Debian 6. I mean, finding python 2.7 in recent Debian stable would be like finding an atomic cannon in a 1'st dynasty Egyptian tomb. So it is in testing, but for replication I like to know where you got it. Python 2.7 from Debian testing works fine here. But ActiveState python (ucs2) segfaults with a = np.array(['0123456789'], 'U') a Segmentation fault The string needs to be long for this to show. Chuck ___
