| msg108914 - (view) |
Author: Brian Curtin (brian.curtin) *  |
Date: 2010-06-29 15:58 |
| Debug and Release builds of py3k both throw up a Visual Studio debugger prompt when running this test on Windows. I don't have much time at the moment to investigate, but I find it odd that this isn't occurring on the two Windows py3k buildbots. Output of the release build after selecting not to debug: C:\python-dev\py3k>PCbuild\amd64\python.exe -m test.regrtest test_capi test_capi test test_capi failed -- Traceback (most recent call last): File "C:\python-dev\py3k\lib\test\test_capi.py", line 50, in test_no_FatalError_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' 1 test failed: test_capi |
|
|
| msg108915 - (view) |
Author: Brian Curtin (brian.curtin) * |
Date: 2010-06-29 15:59 |
| I should also note that this doesn't appear to happen on release31-maint or trunk. |
|
|
| msg110902 - (view) |
Author: Hirokazu Yamamoto (ocean-city) * |
Date: 2010-07-20 14:15 |
| I experienced this crash on test_thread.py. I created a patch hopefully to fix this issue. My knowleage about threading is not so deep, so maybe this patch is not so good. ;-) # I'm worried about COND_RESET which is not used in my patch. But # pthread variant is doing nothing on this macro... Now, test_thread.py runs fine. Reference: http://www.cs.wustl.edu/~schmidt/win32-cv-1.html http://msdn.microsoft.com/en-us/library/ms686293(VS.85).aspx http://www.linux.or.jp/JM/html/glibc-linuxthreads/man3/pthread_cond_init.3.html |
|
|
| msg112128 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2010-07-31 11:00 |
| The patch shouldn't remove COND_RESET, otherwise there will be spurious wakeups. Also, it would be nice to have more precisions about the issue. At which point does PyThreadState_Get() fail? |
|
|
| msg112132 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2010-07-31 11:22 |
| > I don't have much time at the moment to investigate, but I find it odd > that this isn't occurring on the two Windows py3k buildbots. At least two of them (and perhaps the third -- I've asked Paul about it) are single-core virtual machines. What is your setup? |
|
|
| msg112152 - (view) |
Author: Brian Curtin (brian.curtin) * |
Date: 2010-07-31 13:59 |
| Both machines I've seen this on were true multicore, no VMs. One is dual core the other is 16. |
|
|
| msg113155 - (view) |
Author: Hirokazu Yamamoto (ocean-city) * |
Date: 2010-08-07 07:37 |
| I said I saw same crash on test_threading in , but there is possibility that this is different problem. So I'll remove my patch and clear dependencies I set. |
|
|
| msg115246 - (view) |
Author: Stefan Krah (skrah) * |
Date: 2010-08-30 22:11 |
| I see the same crash in test_capi, qemu, Windows 7, Debug|x64. The function crash_no_current_thread() introduced in r81142 ultimately calls Py_FatalError, which then aborts. |
|
|
| msg115249 - (view) |
Author: Stefan Krah (skrah) * |
Date: 2010-08-30 22:41 |
| I just see that the test is running as expected: _testcapi.crash_no_current_thread() is running in a subprocess, so the abort() is harmless on Linux. On Windows, abort() causes the pop-ups, apparently even when it occurs in a subprocess. Perhaps we should generally use an ABORT() macro, which translates to exit() on Windows. |
|
|
| msg115635 - (view) |
Author: Georg Brandl (georg.brandl) * |
Date: 2010-09-05 08:14 |
| Once again, this is not important enough block 3.2a2. |
|
|
| msg115921 - (view) |
Author: Hirokazu Yamamoto (ocean-city) * |
Date: 2010-09-09 00:48 |
| After creating experimental patch, I could supress dialog and error message on VS8.0. But it seems there is no way to suppress error message on VC6. That is, FAILED (failures=1) Traceback (most recent call last): File "e:\python-dev\py3k\lib\runpy.py", line 160, in _run_module_as_main "__main__", fname, loader, pkg_name) File "e:\python-dev\py3k\lib\runpy.py", line 73, in _run_code exec(code, run_globals) File "e:\python-dev\py3k\lib\test\test_capi.py", line 182, in test_main() File "e:\python-dev\py3k\lib\test\test_capi.py", line 143, in test_main support.run_unittest(CAPITest) File "e:\python-dev\py3k\lib\test\support.py", line 1127, in run_unittest _run_suite(suite) File "e:\python-dev\py3k\lib\test\support.py", line 1110, in _run_suite raise TestFailed(err) test.support.TestFailed: Traceback (most recent call last): File "e:\python-dev\py3k\lib\test\test_capi.py", line 50, in test_no_FatalErro r_infinite_loop b'Fatal Python error:' AssertionError: b'Fatal Python error: PyThreadState_Get: no current thread\r\n\r \nabnormal program termination' != b'Fatal Python error: PyThreadState_Get: no c urrent thread' This happens because "abnormal program termination" is output to stderr. Another capable sink to output error message into is messagebox, of cause it is not what we want. There is no way to silent this. I think there are a few options to take. * Skip this test on VC6 (And probably VS7.1) * Check not equality, but if stderr starts with "Fatal Python ...." |
|
|
| msg115931 - (view) |
Author: Hirokazu Yamamoto (ocean-city) * |
Date: 2010-09-09 07:55 |
| Here is the patch. On VS8.0 or above, * Avoid DebugBreak() call by IsDebuggerPresent(). * Tell abort() not to print message to console or window. |
|
|
| msg116008 - (view) |
Author: Hirokazu Yamamoto (ocean-city) * |
Date: 2010-09-10 11:27 |
| Maybe is #5619 related? |
|
|
| msg121187 - (view) |
Author: Stefan Krah (skrah) * |
Date: 2010-11-14 11:27 |
| Hirokazu's patch works for me. Could this approach be taken in general to suppress all buildbot pop-ups? |
|
|
| msg121258 - (view) |
Author: Brian Curtin (brian.curtin) * |
Date: 2010-11-16 03:05 |
| The patch works for me. Unfortunately my knowledge on this particular area is very low so I can't really evaluate the patch. |
|
|
| msg149413 - (view) |
Author: Stefan Krah (skrah) * |
Date: 2011-12-13 22:52 |
| I just tried out http://www.bitvise.com/winsshd , which is free for personal and noncommercial use. If you run the tests via an ssh connection, WinSSHD automatically translates pop-ups into error messages: C:\Users\stefan\cdecimal\PCbuild>python.exe -m test -uall test_capi [1/1] test_capi Warning -- threading._dangling was modified by test_capi test test_capi failed -- Traceback (most recent call last): File "C:\Users\stefan\cdecimal\lib\test\test_capi.py", line 51, in test_no_FatalError_infinite_loop b'Fatal Python error:' AssertionError: b"Fatal Python error: PyThreadState_Get: no current thread\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' 1 test failed: test_capi Thus, by using ... self.assertIn(b'Fatal Python error:', err.rstrip()) in test_capi, the tests pass without any further intervention! This is most interesting, to the point that I'm considering setting up a buildbot. |
|
|
| msg150922 - (view) |
Author: Terry J. Reedy (terry.reedy) * |
Date: 2012-01-09 07:15 |
| I just got 'fatal error' running python_d 3.3.a0 checked out yesterday. When I closed message, test continued (but really crashed later). |
|
|
| msg159982 - (view) |
Author: Vinay Sajip (vinay.sajip) * |
Date: 2012-05-05 09:35 |
| The AssertionError in Brian's initial post indicates that the test is too restrictive. Though the discussion here has talked about removing the popups altogether, the test passes on Windows with a small change: instead of assertEqual(), I used self.assertTrue(err.rstrip().startswith( b'Fatal Python error:' b' PyThreadState_Get: no current thread')) Patch attached. As this seems to be a sufficiently specific test, but not too specific, I'd like to apply this patch soon, unless someone thinks the test needs to stay exactly like it is. |
|
|
| msg160031 - (view) |
Author: Stefan Krah (skrah) * |
Date: 2012-05-05 19:46 |
| I tested the patch, it works fine. I can't test the popup situation since I currently only have ssh access. |
|
|
| msg160072 - (view) |
Author: Roundup Robot (python-dev)  |
Date: 2012-05-06 10:35 |
| New changeset 4d74d275224d by Vinay Sajip in branch 'default': Issue #9116: Allowed test to pass on Windows by adjusting the test condition slightly to allow for a Windows-specific error message. http://hg.python.org/cpython/rev/4d74d275224d |
|
|
| msg182471 - (view) |
Author: Ezio Melotti (ezio.melotti) * |
Date: 2013-02-20 05:41 |
| Vinay commit made the test pass, but the popup is still present. Removing the popup is discussed in #11732. |
|
|
| msg222202 - (view) |
Author: Zachary Ware (zach.ware) * |
Date: 2014-07-03 17:21 |
| With the popup-supression context manager from #11732 in use and the buildbots using the regrtest '-n' option, I think we're at the point of being "fixed enough" and vote to close this issue. I'll leave the final decision to someone with a deeper understanding of the issue, though. |
|
|