This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Unsupported provider

classification
Title: test_capi.test_no_FatalError_infinite_loop crash on Windows
Type: crash Stage:
Components: Interpreter Core, Tests, Windows Versions: Python 3.4, Python 3.5
process
Status: open Resolution:
Dependencies: 5619 Superseder:
Assigned To: Nosy List: brian.curtin, catalin.iacob, ezio.melotti, georg.brandl, ocean-city, pitrou, python-dev, steve.dower, terry.reedy, tim.golden, vinay.sajip, vstinner, zach.ware
Priority: normal Keywords: patch

Created on 2010-06-29 15:58 by brian.curtin, last changed 2022-04-11 14:57 by admin.

Files
File name Uploaded Description Edit
py3k_fix_test_capi_crash.patch ocean-city, 2010-09-09 07:55 review
test_capi.diff vinay.sajip, 2012-05-05 09:35 Slight change to test assertion needed to pass on Windows
Messages (22)
msg108914 - (view) Author: Brian Curtin (brian.curtin) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) Date: 2010-08-07 07:37
I said I saw same crash on test_threading in msg110902, 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) Date: 2010-09-05 08:14
Once again, this is not important enough block 3.2a2.
msg115921 - (view) Author: Hirokazu Yamamoto (ocean-city) * (Python committer) 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 <module>
    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) * (Python committer) 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) * (Python committer) Date: 2010-09-10 11:27
Maybe is #5619 related?
msg121187 - (view) Author: Stefan Krah (skrah) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) (Python triager) 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) * (Python committer) 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) * (Python committer) 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.
History
Date User Action Args
2022-04-11 14:57:03adminsetgithub: 53362
2014-10-14 17:11:48skrahsetnosy: - skrah
2014-07-03 17:21:31zach.waresetmessages: + msg222202
2014-06-30 21:51:30BreamoreBoysetnosy: + tim.golden, zach.ware, steve.dower

versions: + Python 3.5, - Python 3.2, Python 3.3
2013-02-20 05:41:38ezio.melottisetnosy: + ezio.melotti

messages: + msg182471
versions: + Python 3.3, Python 3.4
2012-05-06 10:35:05python-devsetnosy: + python-dev
messages: + msg160072
2012-05-05 19:46:22skrahsetmessages: + msg160031
2012-05-05 09:35:44vinay.sajipsetfiles: + test_capi.diff
nosy: + vinay.sajip
messages: + msg159982

2012-01-09 07:15:26terry.reedysetnosy: + terry.reedy
messages: + msg150922
2011-12-13 22:52:49skrahsetmessages: + msg149413
2011-11-30 12:21:01vstinnersetnosy: + vstinner
2011-11-27 17:41:18catalin.iacobsetnosy: + catalin.iacob
2011-01-30 02:57:56brian.curtinlinkissue11070 superseder
2010-11-16 03:05:03brian.curtinsetmessages: + msg121258
2010-11-14 11:27:26skrahsetmessages: + msg121187
2010-09-10 11:27:50ocean-citysetdependencies: + Pass MS CRT debug flags into subprocesses
messages: + msg116008
2010-09-09 07:55:54ocean-citysetfiles: + py3k_fix_test_capi_crash.patch
keywords: + patch
messages: + msg115931
2010-09-09 00:48:25ocean-citysetpriority: release blocker -> normal
nosy: + ocean-city
messages: + msg115921

2010-09-06 08:26:11georg.brandlsetpriority: deferred blocker -> release blocker
2010-09-05 08:14:09georg.brandlsetpriority: release blocker -> deferred blocker

messages: + msg115635
2010-09-01 19:04:17eric.araujosetkeywords: - patch
2010-08-30 22:41:26skrahsetmessages: + msg115249
2010-08-30 22:11:05skrahsetnosy: + skrah
messages: + msg115246
2010-08-10 11:33:45floxsetnosy: georg.brandl, pitrou, brian.curtin
components: + Windows
2010-08-07 07:38:37ocean-citysetnosy: - ocean-city
2010-08-07 07:37:18ocean-citysetfiles: - py3k_ceval_gil.patch
2010-08-07 07:37:08ocean-citysetdependencies: - New GIL: improve condition variable emulation on NT
messages: + msg113155
2010-08-06 10:50:04ocean-citysetdependencies: + New GIL: improve condition variable emulation on NT
2010-07-31 18:24:42georg.brandlsetpriority: deferred blocker -> release blocker
2010-07-31 13:59:03brian.curtinsetmessages: + msg112152
2010-07-31 13:49:28georg.brandlsetpriority: release blocker -> deferred blocker
2010-07-31 12:05:33pitrousetnosy: + georg.brandl
2010-07-31 11:22:58pitrousetmessages: + msg112132
2010-07-31 11:00:09pitrousetnosy: + pitrou
messages: + msg112128
2010-07-31 07:43:48ocean-citysetpriority: normal -> release blocker
2010-07-20 14:15:27ocean-citysetfiles: + py3k_ceval_gil.patch

nosy: + ocean-city
messages: + msg110902

keywords: + patch
2010-06-29 15:59:51brian.curtinsetmessages: + msg108915
2010-06-29 15:58:26brian.curtincreate