Re: [Cython] Cython Debian builds - failing cygdb tests
Hi, Yaroslav Halchenko retried the test run on Sparc and all code related bugs seem to be resolved now (I had to fix a few minor endianess bugs). However, the cygdb tests still fail, but do not lead to a test run failure. Yaroslav Halchenko, 10.08.2012 01:05:
tested current 0.16rc1-591-g5de843a on sparc -- indeed resolved ;) but then also mentioned that at the beginning there is a separate batch of tests "inside gdb" which seems to fail... they (some or all) also fail on i386 where I have started to rerun now after installing gdb. Full log from sparc: http://www.onerussian.com/tmp/0.16rc1-591-g5de843a-sparc-tests-output.txt
Since gdb might or might not be installed (it is not listed in Build-Depends of the debian package but neither conflicts with having gdb installed) on the build host -- if those failures could be just ignored, I better exclude them explicitly (I guess with --exclude=Debugger)
Is that the expected behaviour? Or is there just something missing in the build server setup, maybe something wrong with the gdb Python plugin? It looks like it's doing something, though... Stefan
On 10 August 2012 05:23, Stefan Behnel <stefan_ml@behnel.de> wrote:
Hi,
Yaroslav Halchenko retried the test run on Sparc and all code related bugs seem to be resolved now (I had to fix a few minor endianess bugs).
However, the cygdb tests still fail, but do not lead to a test run failure.
Yaroslav Halchenko, 10.08.2012 01:05:
tested current 0.16rc1-591-g5de843a on sparc -- indeed resolved ;) but then also mentioned that at the beginning there is a separate batch of tests "inside gdb" which seems to fail... they (some or all) also fail on i386 where I have started to rerun now after installing gdb. Full log from sparc: http://www.onerussian.com/tmp/0.16rc1-591-g5de843a-sparc-tests-output.txt
Since gdb might or might not be installed (it is not listed in Build-Depends of the debian package but neither conflicts with having gdb installed) on the build host -- if those failures could be just ignored, I better exclude them explicitly (I guess with --exclude=Debugger)
Is that the expected behaviour? Or is there just something missing in the build server setup, maybe something wrong with the gdb Python plugin? It looks like it's doing something, though...
IIRC, it parses the gdb version to match against gdb >= 7.2. Something is clearly going wrong, it needs investigation... Unit testing was hard enough on top of dealing with a notoriously unstable Python API, maybe it's using 7.3 and it's backwards incompatible in some subtle way? Or maybe one of the workarounds for gdb bugs were broken by a bug fix? :) No idea really, the tests used to pass with 7.2, no code in the debugger changed really.
Stefan
_______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
On Fri, 10 Aug 2012, mark florisson wrote:
Is that the expected behaviour? Or is there just something missing in the build server setup, maybe something wrong with the gdb Python plugin? It looks like it's doing something, though...
IIRC, it parses the gdb version to match against gdb >= 7.2. Something is clearly going wrong, it needs investigation...
FWIW $> gdb --version GNU gdb (GDB) 7.4.1-debian ... seems to be parsed alright by Cython/Debugger/Tests/TestLibCython.py .
Unit testing was hard enough on top of dealing with a notoriously unstable Python API, maybe it's using 7.3 and it's backwards incompatible in some subtle way?
could be could be... just in case -- tested with gdb 7.3 -- similar failures.
Or maybe one of the workarounds for gdb bugs were broken by a bug fix? :) No idea really, the tests used to pass with 7.2, no code in the debugger changed really.
btw -- with runtests.py is there a built-in way to fall into a debugger (pdb) upon failure/exception handling? -- Yaroslav O. Halchenko Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik
IIRC, it parses the gdb version to match against gdb >= 7.2. Something is clearly going wrong, it needs investigation...
FWIW -- I have built 7.2-1 Debian package (obtained from snapshot.debian.org) under Debian stable squeeze. So I have: ,--- | $> gdb -v | GNU gdb (GDB) 7.2-debian | Copyright (C) 2010 Free Software Foundation, Inc. | License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> | This is free software: you are free to change and redistribute it. | There is NO WARRANTY, to the extent permitted by law. Type "show copying" | and "show warranty" for details. | This GDB was configured as "x86_64-linux-gnu". | For bug reporting instructions, please see: | <http://www.gnu.org/software/gdb/bugs/>. `--- tests still fail, see http://www.onerussian.com/tmp/0.16rc1-595-g36d8cab-amd64-squeeze-gdb7.2-Debu... On Fri, 10 Aug 2012, Yaroslav Halchenko wrote:
Is that the expected behaviour? Or is there just something missing in the build server setup, maybe something wrong with the gdb Python plugin? It looks like it's doing something, though...
FWIW
$> gdb --version GNU gdb (GDB) 7.4.1-debian ...
seems to be parsed alright by Cython/Debugger/Tests/TestLibCython.py . -- Yaroslav O. Halchenko Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik
participants (3)
-
mark florisson -
Stefan Behnel -
Yaroslav Halchenko