Testsuite fails with Python 2.7.3rc1 and 3.2.3rc1 (Debian)
Hello, I've reported http://projects.scipy.org/numpy/ticket/2085 and Ralf asked for bringing that up here: is anyone able to replicate the problem described in that ticket? The debian bug tracking the problem is: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=664672 Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi
On Wed, Mar 21, 2012 at 12:28 AM, Sandro Tosi <matrixhasu@gmail.com> wrote:
Hello, I've reported http://projects.scipy.org/numpy/ticket/2085 and Ralf asked for bringing that up here: is anyone able to replicate the problem described in that ticket?
The debian bug tracking the problem is: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=664672
We do have an Ubuntu buildbot that runs fine with 2.7.2 (see buildbot.scipy.org). Is that failure seen on unusual hardware or with a specific compiler only? Ralf
Hi Ralf sorry for the late reply. On Tue, Mar 27, 2012 at 22:29, Ralf Gommers <ralf.gommers@googlemail.com> wrote:
On Wed, Mar 21, 2012 at 12:28 AM, Sandro Tosi <matrixhasu@gmail.com> wrote:
Hello, I've reported http://projects.scipy.org/numpy/ticket/2085 and Ralf asked for bringing that up here: is anyone able to replicate the problem described in that ticket?
The debian bug tracking the problem is: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=664672
We do have an Ubuntu buildbot that runs fine with 2.7.2 (see buildbot.scipy.org).
ubuntu python and build stack tends to be different than Debian ones, so they are not exactly comparable.
Is that failure seen on unusual hardware or with a specific compiler only?
well, I don't think so. You can check all our archs build log at https://buildd.debian.org/status/package.php?p=python-numpy&suite=experimental but I saw that on my laptop (amd64) an on those logs too. There you can find all the references to the versions of the tools used for the build. Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi
On Sat, Mar 31, 2012 at 12:39 PM, Sandro Tosi <matrixhasu@gmail.com> wrote:
Hi Ralf sorry for the late reply.
On Tue, Mar 27, 2012 at 22:29, Ralf Gommers <ralf.gommers@googlemail.com> wrote:
On Wed, Mar 21, 2012 at 12:28 AM, Sandro Tosi <matrixhasu@gmail.com>
wrote:
Hello, I've reported http://projects.scipy.org/numpy/ticket/2085 and Ralf asked for bringing that up here: is anyone able to replicate the problem described in that ticket?
The debian bug tracking the problem is: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=664672
We do have an Ubuntu buildbot that runs fine with 2.7.2 (see buildbot.scipy.org).
ubuntu python and build stack tends to be different than Debian ones, so they are not exactly comparable.
Is that failure seen on unusual hardware or with a specific compiler only?
well, I don't think so. You can check all our archs build log at
https://buildd.debian.org/status/package.php?p=python-numpy&suite=experimental but I saw that on my laptop (amd64) an on those logs too. There you can find all the references to the versions of the tools used for the build.
Thanks. Can you explain what happens when running the tests? I don't understand why the log says "Fatal Python error...Aborted" and then it happily continues (or restarts) and returns "OK (KNOWNFAIL=3, SKIP=4)" even for the 2.7.3rc1 and 3.2.3rc2 release candidates. Ralf
On Sun, Apr 1, 2012 at 11:32, Ralf Gommers <ralf.gommers@googlemail.com> wrote:
Thanks. Can you explain what happens when running the tests? I don't understand why the log says "Fatal Python error...Aborted" and then it happily continues (or restarts) and returns "OK (KNOWNFAIL=3, SKIP=4)" even for the 2.7.3rc1 and 3.2.3rc2 release candidates.
I think it's some sort of stdout/stderr mixup, where ..... ----- Ran 3541 tests in 26.049s OK (KNOWNFAIL=3, SKIP=4) is printed before the information about the tests, such as: Running unit tests for numpy NumPy version 1.6.1 NumPy is installed in /build/buildd-python-numpy_1.6.1-6-i386-lYkcLV/python-numpy-1.6.1/debian/tmp/usr/lib/python2.7/dist-packages/numpy Python version 2.7.3rc1 (default, Mar 10 2012, 00:01:06) [GCC 4.6.3] nose version 1.1.2 so it might be that only the debug flavors are affected by this problem. Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi
On Sun, Apr 1, 2012 at 12:08 PM, Sandro Tosi <matrixhasu@gmail.com> wrote:
On Sun, Apr 1, 2012 at 11:32, Ralf Gommers <ralf.gommers@googlemail.com> wrote:
Thanks. Can you explain what happens when running the tests? I don't understand why the log says "Fatal Python error...Aborted" and then it happily continues (or restarts) and returns "OK (KNOWNFAIL=3, SKIP=4)" even for the 2.7.3rc1 and 3.2.3rc2 release candidates.
I think it's some sort of stdout/stderr mixup, where
..... ----- Ran 3541 tests in 26.049s
OK (KNOWNFAIL=3, SKIP=4)
is printed before the information about the tests, such as:
Running unit tests for numpy NumPy version 1.6.1 NumPy is installed in
/build/buildd-python-numpy_1.6.1-6-i386-lYkcLV/python-numpy-1.6.1/debian/tmp/usr/lib/python2.7/dist-packages/numpy Python version 2.7.3rc1 (default, Mar 10 2012, 00:01:06) [GCC 4.6.3] nose version 1.1.2
so it might be that only the debug flavors are affected by this problem.
OK, that makes sense. So there are six test runs; for normal and debug builds of 2.6.7, 2.7.3rc1 and 3.2.3rc2. Only the debug builds of the RCs have a problem, debug build of 2.6.7 is fine. So I'd think that most likely there is a problem with how the debug versions of the RCs were built. Ralf
On Sun, Apr 1, 2012 at 12:25, Ralf Gommers <ralf.gommers@googlemail.com> wrote:
OK, that makes sense. So there are six test runs; for normal and debug builds of 2.6.7, 2.7.3rc1 and 3.2.3rc2. Only the debug builds of the RCs have a problem, debug build of 2.6.7 is fine.
exactly.
So I'd think that most likely there is a problem with how the debug versions of the RCs were built.
it sounds possible: is there a way to isolate the failing test, so that I can provide a minimal test code for further investigation to python maintainer? Regards, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi
On Sat, Apr 7, 2012 at 5:32 PM, Sandro Tosi <matrixhasu@gmail.com> wrote:
On Sun, Apr 1, 2012 at 12:25, Ralf Gommers <ralf.gommers@googlemail.com> wrote:
OK, that makes sense. So there are six test runs; for normal and debug builds of 2.6.7, 2.7.3rc1 and 3.2.3rc2. Only the debug builds of the RCs have a problem, debug build of 2.6.7 is fine.
exactly.
So I'd think that most likely there is a problem with how the debug versions of the RCs were built.
it sounds possible: is there a way to isolate the failing test, so that I can provide a minimal test code for further investigation to python maintainer?
Possibly related to ticket #1578<http://projects.scipy.org/numpy/ticket/1578>. Chuck
On Sat, Apr 7, 2012 at 6:41 PM, Charles R Harris <charlesr.harris@gmail.com>wrote:
On Sat, Apr 7, 2012 at 5:32 PM, Sandro Tosi <matrixhasu@gmail.com> wrote:
On Sun, Apr 1, 2012 at 12:25, Ralf Gommers <ralf.gommers@googlemail.com> wrote:
OK, that makes sense. So there are six test runs; for normal and debug builds of 2.6.7, 2.7.3rc1 and 3.2.3rc2. Only the debug builds of the RCs have a problem, debug build of 2.6.7 is fine.
exactly.
So I'd think that most likely there is a problem with how the debug versions of the RCs were built.
it sounds possible: is there a way to isolate the failing test, so that I can provide a minimal test code for further investigation to python maintainer?
Possibly related to ticket #1578<http://projects.scipy.org/numpy/ticket/1578>.
I can reproduce at least one crash with python2.7 debug at arrayobject.c Program received signal SIGSEGV, Segmentation fault. 0x00000036a5882b94 in free () from /lib64/libc.so.6 (gdb) bt #0 0x00000036a5882b94 in free () from /lib64/libc.so.6 #1 0x00007ffff12ce399 in array_dealloc (self=0x1bc50d8) at numpy/core/src/multiarray/arrayobject.c:408 #2 0x00007ffff12b58dd in PyArray_Return (mp=0x1bc50d8) at numpy/core/src/multiarray/scalarapi.c:830 #3 PyArray_Return (mp=0x1bc50d8) at numpy/core/src/multiarray/scalarapi.c:803 #4 0x00007ffff12b5d68 in array_any (array=0x1b69de8, args=<optimized out>, kwds=<optimized out>) at numpy/core/src/multiarray/methods.c I don't know if it is the same. Chuck
Chuck
On Sat, Apr 7, 2012 at 7:04 PM, Charles R Harris <charlesr.harris@gmail.com>wrote:
On Sat, Apr 7, 2012 at 6:41 PM, Charles R Harris < charlesr.harris@gmail.com> wrote:
On Sat, Apr 7, 2012 at 5:32 PM, Sandro Tosi <matrixhasu@gmail.com> wrote:
On Sun, Apr 1, 2012 at 12:25, Ralf Gommers <ralf.gommers@googlemail.com> wrote:
OK, that makes sense. So there are six test runs; for normal and debug builds of 2.6.7, 2.7.3rc1 and 3.2.3rc2. Only the debug builds of the RCs have a problem, debug build of 2.6.7 is fine.
exactly.
So I'd think that most likely there is a problem with how the debug versions of the RCs were built.
it sounds possible: is there a way to isolate the failing test, so that I can provide a minimal test code for further investigation to python maintainer?
Possibly related to ticket #1578<http://projects.scipy.org/numpy/ticket/1578>.
I can reproduce at least one crash with python2.7 debug at arrayobject.c
Program received signal SIGSEGV, Segmentation fault. 0x00000036a5882b94 in free () from /lib64/libc.so.6 (gdb) bt #0 0x00000036a5882b94 in free () from /lib64/libc.so.6 #1 0x00007ffff12ce399 in array_dealloc (self=0x1bc50d8) at numpy/core/src/multiarray/arrayobject.c:408 #2 0x00007ffff12b58dd in PyArray_Return (mp=0x1bc50d8) at numpy/core/src/multiarray/scalarapi.c:830 #3 PyArray_Return (mp=0x1bc50d8) at numpy/core/src/multiarray/scalarapi.c:803 #4 0x00007ffff12b5d68 in array_any (array=0x1b69de8, args=<optimized out>, kwds=<optimized out>) at numpy/core/src/multiarray/methods.c
I don't know if it is the same.
This one occurs in test_api.test_copyto_fromscalar. Chuck
On Sun, Apr 8, 2012 at 02:41, Charles R Harris <charlesr.harris@gmail.com> wrote:
Possibly related to ticket #1578.
yes, that's exactly it:
$ python2.7-dbg -c "import sys ; sys.path.insert(0, '/home/morph/deb/build-area/python-numpy-1.6.1/debian/tmp/usr/lib/python$v/dist-packages/') ; import numpy; numpy.test(verbose=10)" Running unit tests for numpy /usr/lib/pymodules/python2.7/nose/plugins/manager.py:405: UserWarning: Module paste was already imported from None, but /usr/lib/python2.7/dist-packages is being added to sys.path import pkg_resources /usr/lib/pymodules/python2.7/nose/plugins/manager.py:405: UserWarning: Module dap was already imported from None, but /usr/lib/python2.7/dist-packages is being added to sys.path import pkg_resources NumPy version 1.5.1 NumPy is installed in /usr/lib/pymodules/python2.7/numpy Python version 2.7.3rc2 (default, Apr 5 2012, 13:54:40) [GCC 4.6.3] nose version 1.0.0 nose.config: INFO: Excluding tests matching ['f2py_ext', 'f2py_f90_ext', 'gen_ext', 'pyrex_ext', 'swig_ext'] numpy.core.tests.test_arrayprint.TestArrayRepr.test_nan_inf ... ok Ticket 844. ... ok numpy.core.tests.test_blasdot.test_blasdot_used ... ok test_from_object_array (numpy.core.tests.test_defchararray.TestBasic) ... ok test_from_object_array_unicode (numpy.core.tests.test_defchararray.TestBasic) ... ok test_from_string (numpy.core.tests.test_defchararray.TestBasic) ... ok test_from_string_array (numpy.core.tests.test_defchararray.TestBasic) ... ok test_from_unicode (numpy.core.tests.test_defchararray.TestBasic) ... Debug memory block at address p=0x2ec3cc0: API 'm' 8 bytes originally requested The 7 pad bytes at p-7 are FORBIDDENBYTE, as expected. The 8 pad bytes at tail=0x2ec3cc8 are FORBIDDENBYTE, as expected. The block was made by call #7954800 to debug malloc/realloc. Data at p: a3 03 00 00 00 00 00 00 Fatal Python error: bad ID: Allocated using API 'm', verified using API 'o' Aborted <<<
I've replied to the Trac issue attaching 2 gdb output files for 2.7.3rc2 and 3.2.3rc2 in debug flavor. If you want me to test anything, I'd be happy to. Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi
On Sun, Apr 8, 2012 at 2:28 AM, Sandro Tosi <matrixhasu@gmail.com> wrote:
On Sun, Apr 8, 2012 at 02:41, Charles R Harris <charlesr.harris@gmail.com> wrote:
Possibly related to ticket #1578.
yes, that's exactly it:
$ python2.7-dbg -c "import sys ; sys.path.insert(0,
'/home/morph/deb/build-area/python-numpy-1.6.1/debian/tmp/usr/lib/python$v/dist-packages/') ; import numpy; numpy.test(verbose=10)" Running unit tests for numpy /usr/lib/pymodules/python2.7/nose/plugins/manager.py:405: UserWarning: Module paste was already imported from None, but /usr/lib/python2.7/dist-packages is being added to sys.path import pkg_resources /usr/lib/pymodules/python2.7/nose/plugins/manager.py:405: UserWarning: Module dap was already imported from None, but /usr/lib/python2.7/dist-packages is being added to sys.path import pkg_resources NumPy version 1.5.1 NumPy is installed in /usr/lib/pymodules/python2.7/numpy Python version 2.7.3rc2 (default, Apr 5 2012, 13:54:40) [GCC 4.6.3] nose version 1.0.0 nose.config: INFO: Excluding tests matching ['f2py_ext', 'f2py_f90_ext', 'gen_ext', 'pyrex_ext', 'swig_ext'] numpy.core.tests.test_arrayprint.TestArrayRepr.test_nan_inf ... ok Ticket 844. ... ok numpy.core.tests.test_blasdot.test_blasdot_used ... ok test_from_object_array (numpy.core.tests.test_defchararray.TestBasic) ... ok test_from_object_array_unicode (numpy.core.tests.test_defchararray.TestBasic) ... ok test_from_string (numpy.core.tests.test_defchararray.TestBasic) ... ok test_from_string_array (numpy.core.tests.test_defchararray.TestBasic) ... ok test_from_unicode (numpy.core.tests.test_defchararray.TestBasic) ... Debug memory block at address p=0x2ec3cc0: API 'm' 8 bytes originally requested The 7 pad bytes at p-7 are FORBIDDENBYTE, as expected. The 8 pad bytes at tail=0x2ec3cc8 are FORBIDDENBYTE, as expected. The block was made by call #7954800 to debug malloc/realloc. Data at p: a3 03 00 00 00 00 00 00 Fatal Python error: bad ID: Allocated using API 'm', verified using API 'o' Aborted <<<
I've replied to the Trac issue attaching 2 gdb output files for 2.7.3rc2 and 3.2.3rc2 in debug flavor. If you want me to test anything, I'd be happy to.
I've closed #2085 as a duplicate of #1578. Trying to track this down is a hike through the swamp without waders... Chuck
participants (3)
-
Charles R Harris -
Ralf Gommers -
Sandro Tosi