On Wed, Jan 5, 2011 at 17:56, Brian Curtin brian.curtin@gmail.com wrote:

On Wed, Jan 5, 2011 at 17:47, Terry Reedy tjreedy@udel.edu wrote:

...

To test Brett's test running instruction, I ran python -m test # not ./Python! in a Command Prompt window

---

Microsoft Windows XP [Version 5.1.2600]

== CPython 3.2b2 (r32b2:87398, Dec 19 2010, 22:51:00) [MSC v.1500 32 bit (Intel)] == Windows-XP-5.1.2600-SP3 little-endian == c:\docume~1\terry\locals~1\temp\test_python_3528 [ 1/351] test_grammar ... [ 10/351] test___all__ Warning -- os.environ was modified by test___all__ [ 11/351] test___future__ ... [ 37/351] test_capi

Window hangs, can only close. Error popup says "python.exe has encountered a problem..." at 000a03f7 in python32.dll

RUN 2, same command, I get [ 37/351] test_capi test test_capi failed -- Traceback (most recent call last): File "C:\Programs\Python32\lib\test\test_capi.py", line 50, in test_no_FatalEr ror_infinite_loop b'Fatal Python error:' AssertionError: b"Fatal Python error: PyThreadState_Get: no current thread\r\n\r \nThis application has requested the Runtime to terminate it in an unusual way.\ nPlease contact the application's support team for more information." != b'Fatal Python error: PyThreadState_Get: no current thread'

and it continued on with test_cfgparser, etc, so crashing rather than mere failure is intermitant.

BUT process then stopped (hung, no error popup) at [ 67/351] test_concurrent_futures Traceback (most recent call last): File "<string>", line 1, in <module> File "C:\Programs\Python32\lib\multiprocessing\forking.py", line 369, in main prepare(preparation_data) File "C:\Programs\Python32\lib\multiprocessing\forking.py", line 477, in prepa re assert main_name not in sys.modules, main_name AssertionError: __main__

RUN 3 python -m test -x test_capi test_concurrent_futures

went further, more failed tests, then process started repeatedly (hundred of times) outputting

assert main_name not in sys.modules, main_name AssertionError: __main__ Traceback (most recent call last): File "<string>", line 1, in <module> File "C:\Programs\Python32\lib\multiprocessing\forking.py", line 369, in main prepare(preparation_data) File "C:\Programs\Python32\lib\multiprocessing\forking.py", line 477,

Occasionally a new test would start in between this stuff. It ended with test_sax. I cannot say when it began because the volume overfilled the output buffer.

[306/349] test_ttk_guionly # and test_tk test_ttk_guionly skipped -- ttk not available: Can't find a usable init.tcl in t he following directories: C:/Programs/Python32/lib/tcl8.5 C:/Programs/lib/tcl8.5 C:/lib/tcl8.5 C:/Prog rams/library C:/library C:/tcl8.5.9/library C:/tcl8.5.9/library This probably means that Tcl wasn't installed properly.

Funny, IDLE works fine. In any case, I did a standard install from the distributed installer.

Something is definitely not ready for final release. The final mishmash:

[349/349] test_zlib 295 tests OK. 11 tests failed: test_datetime test_difflib.bak test_ftplib test_lib2to3 test_multiprocessing test_os.bak test_pep277 test_pkgutil test_posixpath test_runpy test_tcl 2 tests altered the execution environment: test___all__ test_site 41 tests skipped: test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_crypt test_curses test_dbm_gnu test_dbm_ndbm test_epoll test_fcntl test_fork1 test_gdb test_grp test_ioctl test_kqueue test_largefile test_nis test_openpty test_ossaudiodev test_pipes test_poll test_posix test_pty test_pwd test_readline test_resource test_smtpnet test_socketserver test_syslog test_threadsignals test_timeout test_tk test_ttk_guionly test_urllib2net test_urllibnet test_wait3 test_wait4 test_winsound test_xmlrpc_net test_zipfile64 4 skips unexpected on win32: test_gdb test_readline test_tk test_ttk_guionly Traceback (most recent call last): File "C:\Programs\Python32\lib\test\support.py", line 468, in temp_cwd yield os.getcwd() File "C:\Programs\Python32\lib\test__main__.py", line 13, in <module> regrtest.main() File "C:\Programs\Python32\lib\test\regrtest.py", line 704, in main sys.exit(len(bad) > 0 or interrupted) SystemExit: True

During handling of the above exception, another exception occurred:

Traceback (most recent call last): File "C:\Programs\Python32\lib\runpy.py", line 160, in _run_module_as_main "__main__", fname, loader, pkg_name) File "C:\Programs\Python32\lib\runpy.py", line 73, in _run_code exec(code, run_globals) File "C:\Programs\Python32\lib\test__main__.py", line 13, in <module> regrtest.main() File "C:\Programs\Python32\lib\contextlib.py", line 46, in __exit__ self.gen.throw(type, value, traceback) File "C:\Programs\Python32\lib\test\support.py", line 472, in temp_cwd rmtree(name) File "C:\Programs\Python32\lib\test\support.py", line 198, in rmtree shutil.rmtree(path) File "C:\Programs\Python32\lib\shutil.py", line 287, in rmtree onerror(os.rmdir, path, sys.exc_info()) File "C:\Programs\Python32\lib\shutil.py", line 285, in rmtree os.rmdir(path) WindowsError: [Error 32] The process cannot access the file because it is being used by another process: 'c:\docume~1\terry\locals~1\temp\test_python_2372'

Traceback (most recent call last): File "C:\Programs\Python32\lib\multiprocessing\util.py", line 261, in _run_fin alizers finalizer() File "C:\Programs\Python32\lib\multiprocessing\util.py", line 200, in __call__

res = self._callback(*self._args, **self._kwargs) File "C:\Programs\Python32\lib\multiprocessing\pool.py", line 492, in _termina te_pool p.terminate() File "C:\Programs\Python32\lib\multiprocessing\process.py", line 137, in termi nate self._popen.terminate() AttributeError: 'NoneType' object has no attribute 'terminate'

C:\Programs\Python32>Traceback (most recent call last): File "<string>", line 1, in <module> File "C:\Programs\Python32\lib\multiprocessing\forking.py", line 368, in main preparation_data = load(from_parent) EOFError

-- Terry Jan Reedy

http://bugs.python.org/issue9116 covers this issue.

The reason it doesn't fail on any of the build slaves is because they modify a registry value for Windows Error Reporting to not display the pop-up window, or at least mine does. I think I got the idea from one of the other Windows build slave maintainers.

Sorry, should have specified -- that issue only covers the test_capi failure.

Brian Curtin brian.curtin@gmail.com writes:

http://bugs.python.org/issue9116 covers this issue.

The reason it doesn't fail on any of the build slaves is because they modify a registry value for Windows Error Reporting to not display the pop-up window, or at least mine does. I think I got the idea from one of the other Windows build slave maintainers.

(delayed message as I was traveling)

Note that the buildbot handling only prevents the pop-up dialogs. The underlying test that would have generated the dialog should still fail if the pop-up would have represented a failure, either through the Win32 API call failure, or the C RTL assertion termination the process with an error exit code.

How that happens varies (OS dialogs are prevented from ever occurring, while C RTL dialogs have a scripted "OK" button press). There have been experiments with disabling the C RTL within Python itself in the past but never quite became consistent enough to trust on the buildbot (at least for me).

But if somehow this is preventing a test failure from being detected on the buildbots, that's certainly an issue, and might indicate that some parent code to that causing the error isn't properly detecting it, either through an API error result, or process termination code.

Of course, if the pop-up is not due to something considered a failure, then yes, the buildbot won't reflect what an actual user may see. I guess 9116 is an error in a child process which under Linux just terminates but under Win32 generates the pop-up, so perhaps aside from the pop-up, the test is assuming such an erroneous termination is acceptable? In such a case, then the approach in 9116 to permit control over the RTL is probably the only choice, but I don't think I see any way to accurately test that fact via the buildbots, since permitting such pop-ups are so disastrous to the overall build process.

-- David

On 1/5/2011 8:59 PM, Nick Coghlan wrote:

On Thu, Jan 6, 2011 at 9:47 AM, Terry Reedytjreedy@udel.edu wrote:

...

To test Brett's test running instruction, I ran python -m test # not ./Python! in a Command Prompt window

Does it behave itself if you add "-x test_capi" to the command line?

No, it gets worse. Really. Let me summarize a long post.

Run 1: normal (as above) Process stops at capi test with Windows error message. Close command prompt window with [x] buttom (crtl-whatever had no effect).

Run 2: normal (as before) Process reported capi test failure (supposedly fatal) but continued. Process just stopped ('hung') at concurrent futures. Close as before.

Run 3: -x test_capi test_concurrent_futures Instead of the normal output I expected, I got some of the craziest stuff I have ever seen. Things like " assert main_name not in sys.modules, main_name AssertionError: __main__ Traceback (most recent call last): File "<string>", line 1, in <module> File "C:\Programs\Python32\lib\multiprocessing\forking.py", line 369, in main prepare(preparation_data) File "C:\Programs\Python32\lib\multiprocessing\forking.py", line 477, " were printed 100s of times intermixed with the normal sequential test startup lines. They stopped after text_sax started and output became normal through the end of the report.

295 tests OK. 11 tests failed: test_datetime test_difflib.bak test_ftplib test_lib2to3 test_multiprocessing test_os.bak test_pep277 test_pkgutil test_posixpath test_runpy test_tcl 2 tests altered the execution environment: test___all__ test_site 41 tests skipped: [snip] 4 skips unexpected on win32: test_gdb test_readline test_tk test_ttk_guionly (It previously said it could not find tk (or ttk), even though IDLE does just fine.)

Then chained error craziness during shutdown: SystemExit, WindowsError, AttributeError, EOFError (details in original post).

I forgot to mention before that test_ftplib runs into Windows security and pops up a window (which I closed).

If I did not know better, I might have thought python to be a buggy piece of junk, but my well-tested package-in-progress runs fine (from IDLE edit window) in 3.2b2, unchanged from 3.1. I think fixing test regressions should happen before a 'release candidate'.

On same machine (again, installed from Martin's .msi) C:\Programs\Python31>python -m test.regrtest seems to run 'normally' (same security popup), no craziness (except for blocked ftplib test), with results

298 tests OK. 3 tests failed: test_ftplib test_lib2to3 test_tcl 39 tests skipped: [snip] 2 skips unexpected on win32: test_tk test_ttk_guionly

test_tcl had multiple errors, tk,ttk skips are from not finding usable init.tcl

Similar result with 2.7 with addition of test_distutils failure and 'unexpected skips' of test_gbd and test_readline (but I presume these really should be expected).

On Thu, Jan 6, 2011 at 4:00 PM, Terry Reedy tjreedy@udel.edu wrote:

...

Does it behave itself if you add "-x test_capi" to the command line?

No, it gets worse. Really. Let me summarize a long post.

Run 1: normal (as above) Process stops at capi test with Windows error message. Close command prompt window with [x] buttom (crtl-whatever had no effect).

Run 2: normal (as before) Process reported capi test failure (supposedly fatal) but continued. Process just stopped ('hung') at concurrent futures. Close as before.

Run 3: -x test_capi test_concurrent_futures Instead of the normal output I expected, I got some of the craziest stuff I have ever seen. Things like

Does it all go back to normal if you use "python -m test.regrtest" instead? Antoine discovered that multiprocessing on Windows gets thoroughly confused if __file__ in the main module ends with "__main__.py" (see http://bugs.python.org/issue10845)

Cheers, Nick.