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

I should also note that this doesn't appear to happen on release31-maint or trunk.

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

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?

> 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?

Both machines I've seen this on were true multicore, no VMs. One is dual core the other is 16.

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.

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.

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.

Once again, this is not important enough block 3.2a2.

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 ...."

Here is the patch. On VS8.0 or above,
* Avoid DebugBreak() call by IsDebuggerPresent().
* Tell abort() not to print message to console or window.

Maybe is #5619 related?

Hirokazu's patch works for me. Could this approach be taken in general to
suppress all buildbot pop-ups?

The patch works for me.
Unfortunately my knowledge on this particular area is very low so I can't really evaluate the patch.

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.

I just got 'fatal error' running python_d 3.3.a0 checked out yesterday. When I closed message, test continued (but really crashed later).

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.

I tested the patch, it works fine. I can't test the popup situation
since I currently only have ssh access.

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

Vinay commit made the test pass, but the popup is still present.
Removing the popup is discussed in #11732.

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.