homepage

With the latest py3k, some tests fail when run in debug mode:
- test_distutils fails with the following message:
FAILED (errors=1)
Traceback (most recent call last):
 File "Lib/test/test_distutils.py", line 17, in <module>
test_main()
 File "Lib/test/test_distutils.py", line 13, in test_main
test.support.run_unittest(distutils.tests.test_suite())
 File "/home/antoine/py3k/pristine/Lib/test/support.py", line 717, in
run_unittest
_run_suite(suite)
 File "/home/antoine/py3k/pristine/Lib/test/support.py", line 700, in
_run_suite
raise TestFailed(err)
test.support.TestFailed: Traceback (most recent call last):
 File
"/home/antoine/py3k/pristine/Lib/distutils/tests/test_build_ext.py",
line 48, in test_build_ext
 import xx
AttributeError: mro
- test_set crashes with the following message:
./python Lib/test/test_set.py 
test_add (__main__.TestSet) ... ok
test_and (__main__.TestSet) ... ok
test_badcmp (__main__.TestSet) ... ok
test_c_api (__main__.TestSet) ... Fatal Python error:
Objects/setobject.c:2429 object at 0xb797ce04 has negative ref count -1
Abandon

I'll look at the test_set failure if no one else gets to it first.

Neither of these fail for me on MacOS.

On another machine, with another distro (Debian stable) and another gcc
version (4.1.2 instead of 4.3.1), I even get a segmentation fault on
test_distutils:
$ ./python Lib/test/test_set.py 
test_add (__main__.TestSet) ... ok
test_and (__main__.TestSet) ... ok
test_badcmp (__main__.TestSet) ... ok
test_c_api (__main__.TestSet) ... Fatal Python error:
Objects/setobject.c:2429 object at 0xb761ce04 has negative ref count -1
Abandon
$ ./python Lib/test/test_distutils.py 
test_build_ext (distutils.tests.test_build_ext.BuildExtTestCase) ...
Erreur de segmentation

I can't reproduce the error using Windows.

Hmm, ok. I was using `make EXTRA_CFLAGS="-DPy_DEBUG"`, but it wouldn't
undefine NDEBUG so the assert() macro wouldn't be enabled.
By using `make EXTRA_CFLAGS="-DPy_DEBUG -UNDEBUG"` instead it's fine.
But that makes test_c_api in setobject.c bogus, because it relies on the
execution of assert() statements to modify the refcount of certain
objects - which doesn't happen when assert() is optimized out. The only
reason it doesn't crash in non-debug mode is that the deallocated
objects are still intact in memory, and Py_REFCNT simply drops their
refcount field to -1 without bothering.
It also means the following statement in Misc/SpecialBuilds.txt is
misleading:
« Py_DEBUG implies LLTRACE, Py_REF_DEBUG, Py_TRACE_REFS, and
PYMALLOC_DEBUG (if WITH_PYMALLOC is enabled). In addition, C
assert()s are enabled (via the C way: by not defining NDEBUG) »
I haven't looked at the distutils problem yet.

> Py_REFCNT simply drops their refcount field to -1 without bothering.
I meant Py_DECREF.