[Jason Tishler]
> I get the following:
>
> $ ./python.exe -E -tt ../Lib/test/regrtest.py -l -x test_poll \
> test_popen test_popen2 test_pty test_queue test_select
> test_signal \ test_socket test_tempfile test_thread test_grammar
> [snip]
> test_zlib
> 210 tests OK.
> 4 tests failed:
> test___all__ test_csv test_netrc test_time
> 31 tests skipped:
> test_aepack test_al test_bsddb185 test_bsddb3 test_cd test_cl
> test_curses test_dbm test_email_codecs test_gl test_imgfile
> test_ioctl test_largefile test_linuxaudiodev test_locale
> test_macfs test_macostools test_mpz test_nis
> test_normalization test_ossaudiodev test_pep277 test_plistlib
> test_scriptpackages test_socketserver test_sunaudiodev
> test_timeout test_unicode_file test_urllibnet test_winreg
> test_winsound 1 skip unexpected on cygwin:
> test_ioctl
>
> Note that the excluded tests above work fine when run separately:
>
> $ ./python.exe -E -tt ../Lib/test/regrtest.py -l test_poll \
> test_popen test_popen2 test_pty test_queue test_select
> test_signal \ test_socket test_tempfile test_thread
> test_poll
> test_popen
> test_popen2
> test_pty
> test_queue
> test_select
> test_signal
> test_socket
> test_tempfile
> test_thread
> All 10 tests OK.
>
> I appreciate the heads up. I will dig deeper...
I've got a bad feeling that we may have a wild store (or such like) in 2.3.
A day or two ago, Jeremy got a senseless and irreproducible error when
running a ZODB test after compiling with 2.3 CVS, and just now I tried
running regrtest with -r on Win98SE (-r randomizes test case order). That
triggered an error I've never seen before and can't reproduce:
test test_time failed -- Traceback (most recent call last):
File "C:\CODE\PYTHON\lib\test\test_time.py", line 49, in test_strptime
self.fail('conversion specifier: %r failed.' % format)
File "C:\CODE\PYTHON\lib\unittest.py", line 260, in fail
raise self.failureException, msg
AssertionError: conversion specifier: ' %c' failed.
Nothing *screams* "wild store", though. For example, the failure in
test_time may be due to some other test mucking with locale but not cleaning
up after itself -- I simply don't know, and (worse) don't have time to pour
into it.
Possible helps: Check out regrtest's -f option (great for doing "binary
searches" when a failure depends on running a certain subset of tests in a
certain order). Try running the tests under a debug build (pymalloc's
debugging armor in 2.3 debug builds catches many problems). If you get a
reproducible baffling failure, try disabling cyclic gc (import gc;
gc.disable()) to see whether the problem goes away (problems never get
pinned on cyclic gc, but cyclic gc is often sensitive to out-of-bounds
writes elsewhere).
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4