[Neal Norwitz] > There were some SystemErrors on one of the Windows build slaves. Not always, though -- looks to be rare. > Does anyone have any ideas what might be the cause? I looked through about > 5 previous logs on the same slave and didn't see the same problem. I'm home today and fired up my slave, and no problem there either. > I haven't seen this myself and I don't know if it's WIndows specific. I > don't know if this has happened on the trunk or just 2.5. Me neither. > For the full log see: > http://python.org/dev/buildbot/2.5/x86%20XP%202.5/builds/197/step-test/0 > > n > -- > > *** Previous context (I don't think this really matters): > > Re-running test 'test_profilehooks' in verbose mode > test_caught_exception (test.test_profilehooks.ProfileHookTestCase) ... ok > test_caught_nested_exception (test.test_profilehooks.ProfileHookTestCase) ... ok > test_distant_exception (test.test_profilehooks.ProfileHookTestCase) ... ok > test_exception (test.test_profilehooks.ProfileHookTestCase) ... ok > test_exception_in_except_clause > (test.test_profilehooks.ProfileHookTestCase) ... ok > test_exception_propogation (test.test_profilehooks.ProfileHookTestCase) ... ok > test_generator (test.test_profilehooks.ProfileHookTestCase) ... ok > test_nested_exception (test.test_profilehooks.ProfileHookTestCase) ... ok > test_raise (test.test_profilehooks.ProfileHookTestCase) ... ok > test_raise_reraise (test.test_profilehooks.ProfileHookTestCase) ... ok > test_raise_twice (test.test_profilehooks.ProfileHookTestCase) ... ok > test_simple (test.test_profilehooks.ProfileHookTestCase) ... ok > test_stop_iteration (test.test_profilehooks.ProfileHookTestCase) ... ok > test_basic_exception (test.test_profilehooks.ProfileSimulatorTestCase) ... ok > test_caught_exception (test.test_profilehooks.ProfileSimulatorTestCase) ... ok > test_distant_exception (test.test_profilehooks.ProfileSimulatorTestCase) ... ok > test_simple (test.test_profilehooks.ProfileSimulatorTestCase) ... ok > > ---------------------------------------------------------------------- > Ran 17 tests in 0.016s > > OK > > *** Here is the problem: > > Exception exceptions.SystemError: 'error return without exception set' in <generator object at 0x00CCCDF8> ignored > Exception exceptions.SystemError: 'error return without exception set' in <generator object at 0x010891F8> ignored > Exception exceptions.SystemError: 'error return without exception set' in <generator object at 0x01089578> ignored > Exception exceptions.SystemError: 'error return without exception set' in <generator object at 0x01089838> ignored > Exception exceptions.SystemError: 'error return without exception set' in <generator object at 0x00D3BFB8> ignored > *** The following messages occur in other successful tests too: > a DOS box should flash briefly ... Always happens in test_subprocess, during the Windows-specific test_creationflags. This is expected. When you /watch/ the tests running on Windows, it's intended to prevent panic when a mysterious DOS box appears ;-) > find_library('c') -> None > find_library('m') -> None Mysterious. Looks like debug/trace(!) output while running Lib/ctypes/test/test_loading.py's test_find(). > C:\buildbot_py25\2.5.mcintyre-windows\build\lib\test\test_unicode_file.py:103: > UnicodeWarning: Unicode equal comparison failed to convert both > arguments to Unicode - interpreting them as being unequal > filename1==filename2 > C:\buildbot_py25\2.5.mcintyre-windows\build\lib\shutil.py:36: > UnicodeWarning: Unicode equal comparison failed to convert both > arguments to Unicode - interpreting them as being unequal > os.path.normcase(os.path.abspath(dst))) Those started showing up months ago. > warning: DBTxn aborted in destructor. No prior commit() or abort(). Likewise, from the bsddb test, and we've been seeing this one on Unixish boxes too.
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