You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Skip decorator for tests requiring manual intervention on Windows #55941
Attached is a patch which adds skip_unless_unattended, which ideally would be used with at least test_faulthandler when running on Windows.
Running the tests on a Windows desktop results in the user having to click through Windows Error Reporting dialogs in order to continue. Build slaves disable or handle WER dialogs in order to continue running without manual intervention. The patch looks in the common registry keys [0,1] to see the status of WER and skips tests when it finds that WER is enabled and would require user intervention.
We may want to additionally hook this up to a regrtest command line parameter to override the registry setting.
Maybe there's a better name for the decorator - I'm not stuck with what I suggested. I consider build slaves as running in "unattended" mode as opposed to a human kicking off the tests.
Ah yes, I have also issues with the Windows fault handler (the popup). I disabled this popup manually in my Windows XP box.
Instead of skipping the test, I prefer to disable temporary the popup by setting the right registry key (and then restore the previous value or delete the key).
faulthandler causes fatal errors, but test_capi does also test a crash (I don't know which test exactly). I always have to click on the popup to continue to execute the test suite :-(
If we should to disable the Windows fault handler, we may also disable these tools.
test_faulthandler already disable another fault handler: it disables the creation of core files. prepare_subprocess() calls setrlimit(RLIMIT_CORE, (0, 0)).
Disabling and re-enabling is another possibility, and it's probably more likely to help in the long run. Most (all?) Windows machines have error reporting enabled unless you mess with the registry manually, so the only place tests would be run with my first patch would be on build slaves.
I don't currently have a Ubuntu or Fedora machine, but I could look into it. I'll write up a patch that disables/re-enables for Windows and see how it works.
Issue bpo-12481 has been marked as duplicate: "I'm getting the dreaded "python_d.exe has stopped working" popups in test_faulthandler on Windows 7 + VisualStudioPro + "Debug|x64"."
"Most (all?) Windows machines have error reporting enabled unless you mess with the registry manually"
It is disabled on all Windows buildbots. test_capi does also test a crash (I don't know/remember which test exactly).
skrah commented on Jul 3, 2011
skrahmannequin
Mannequin
More actions
For test_capi the patch in bpo-9116 works. For test_faulthandler it
doesn't, unfortunately.
skrah commented on Jul 3, 2011
skrahmannequin
Mannequin
More actions
"Instead of skipping the test, I prefer to disable temporary the popup by setting the right registry key (and then restore the previous value or delete the key)."
Do you mean that the user should change/restore the key or that the
Python tests should do that? I think we shouldn't mess with system
settings, even if we restore them.
BTW, it would be a great help to print a warning (also in test_capi)
that the popups are expected.
There could be a dll which would do nothing when receiving the crash report for expected crashes (test_capi and test_faulthandler). WerRegisterRuntimeExceptionModule doesn't exist in the headers of the SDK that comes with VS2008 but it could be retrieved at runtime with GetProcAddress. It's more work than the registry setting but seems cleaner since it avoids changing system settings.
Here is a proof of concept patch that defines a context manager that disables the crash popups using SetErrorMode 0. I tested it only on Windows 7 (and Linux, where it's a no-op). As an example, the patch fixes the crash popup caused by test_capi.
FWIW I attempted to use WerRegisterRuntimeExceptionModule too, and I was able to access it from ctypes.windll.kernel32.WerRegisterRuntimeExceptionModule on Win7, but then it wanted me to define a DLL with 3 functions, so I tried to find a simpler solution.
renamed the context manager from no_crash_popups to suppress_crash_popup, as suggested by Brian (I also made it singular, because there shouldn't be more than one crash/popup per call);
used the context manager on all the crashing tests (test_capi and test_faulthandler);
added documentation;
I tested it on Windows 7 and Linux (where it's a no-op), and according to MSDN it should work even on Windows XP. If there aren't other comments I'll commit this soon. If test_capi is also crashing on 2.7/3.2, I will probably backport it there too.
I applied this only on 3.3/3.x because I didn't manage to test on 2.7/3.2.
If test_ctypes and/or other tests are failing there I can backport it, but the patch needs to be tweaked there because it doesn't apply cleanly (and there's no test_faulthandler there).
New changeset c0c440dcb8dd by Ezio Melotti in branch '3.2': bpo-11732: add a new suppress_crash_popup() context manager to test.support that disables crash popups on Windows and use it in test_ctypes. http://hg.python.org/cpython/rev/c0c440dcb8dd
GetErrorMode wasn't available on XP/2k3, so I changed the patch to use only SetErrorMode. I also backported it to 3.2, since ctypes has the same crashing test of 3.3/default.
If I got everything right there shouldn't be anymore crash popups while running the tests, however I haven't tested this on 2.7/3.2, so there might be other popups that I missed. If there are, feel free to reopen the issue.
Activity
briancurtin commentedon Mar 31, 2011
Attached is a patch which adds skip_unless_unattended, which ideally would be used with at least test_faulthandler when running on Windows.
Running the tests on a Windows desktop results in the user having to click through Windows Error Reporting dialogs in order to continue. Build slaves disable or handle WER dialogs in order to continue running without manual intervention. The patch looks in the common registry keys [0,1] to see the status of WER and skips tests when it finds that WER is enabled and would require user intervention.
We may want to additionally hook this up to a regrtest command line parameter to override the registry setting.
Maybe there's a better name for the decorator - I'm not stuck with what I suggested. I consider build slaves as running in "unattended" mode as opposed to a human kicking off the tests.
[0] http://www.spyany.com/program/registry-disable-error-reporting.htm
[1] http://msdn.microsoft.com/en-us/library/bb513638(v=vs.85).aspx
briancurtin commentedon Mar 31, 2011
Attached is an example of how this might be used with Lib/test/test_faulthandler.py
vstinner commentedon Mar 31, 2011
Ah yes, I have also issues with the Windows fault handler (the popup). I disabled this popup manually in my Windows XP box.
Instead of skipping the test, I prefer to disable temporary the popup by setting the right registry key (and then restore the previous value or delete the key).
faulthandler causes fatal errors, but test_capi does also test a crash (I don't know which test exactly). I always have to click on the popup to continue to execute the test suite :-(
vstinner commentedon Mar 31, 2011
Ubuntu has also a fault handler: Apport.
https://wiki.ubuntu.com/Apport
Fedora has abrt.
https://fedorahosted.org/abrt/wiki
http://fedoraproject.org/wiki/Features/ABRT
If we should to disable the Windows fault handler, we may also disable these tools.
test_faulthandler already disable another fault handler: it disables the creation of core files. prepare_subprocess() calls setrlimit(RLIMIT_CORE, (0, 0)).
briancurtin commentedon Apr 6, 2011
Disabling and re-enabling is another possibility, and it's probably more likely to help in the long run. Most (all?) Windows machines have error reporting enabled unless you mess with the registry manually, so the only place tests would be run with my first patch would be on build slaves.
I don't currently have a Ubuntu or Fedora machine, but I could look into it. I'll write up a patch that disables/re-enables for Windows and see how it works.
vstinner commentedon Jul 3, 2011
Issue bpo-12481 has been marked as duplicate: "I'm getting the dreaded "python_d.exe has stopped working" popups in test_faulthandler on Windows 7 + VisualStudioPro + "Debug|x64"."
vstinner commentedon Jul 3, 2011
"Most (all?) Windows machines have error reporting enabled unless you mess with the registry manually"
It is disabled on all Windows buildbots. test_capi does also test a crash (I don't know/remember which test exactly).
skrah commentedon Jul 3, 2011
For test_capi the patch in bpo-9116 works. For test_faulthandler it
doesn't, unfortunately.
skrah commentedon Jul 3, 2011
"Instead of skipping the test, I prefer to disable temporary the popup by setting the right registry key (and then restore the previous value or delete the key)."
Do you mean that the user should change/restore the key or that the
Python tests should do that? I think we shouldn't mess with system
settings, even if we restore them.
BTW, it would be a great help to print a warning (also in test_capi)
that the popups are expected.
vstinner commentedon Jul 3, 2011
Python can change temporary the registry value for the duration of the test.
cataliniacob commentedon Nov 27, 2011
To avoid messing with system registry settings it sounds like WerRegisterRuntimeExceptionModule could also work, at least on Windows7 http://msdn.microsoft.com/en-us/library/windows/desktop1/dd408167%28v=VS.85%29.aspx
There could be a dll which would do nothing when receiving the crash report for expected crashes (test_capi and test_faulthandler). WerRegisterRuntimeExceptionModule doesn't exist in the headers of the SDK that comes with VS2008 but it could be retrieved at runtime with GetProcAddress. It's more work than the registry setting but seems cleaner since it avoids changing system settings.
briancurtin commentedon Nov 27, 2011
That would certainly be preferable when available on Windows 7. I'll look into how we can incorporate that.
Thanks for the idea!
ezio-melotti commentedon Feb 20, 2013
Here is a proof of concept patch that defines a context manager that disables the crash popups using SetErrorMode 0. I tested it only on Windows 7 (and Linux, where it's a no-op). As an example, the patch fixes the crash popup caused by test_capi.
FWIW I attempted to use WerRegisterRuntimeExceptionModule too, and I was able to access it from ctypes.windll.kernel32.WerRegisterRuntimeExceptionModule on Win7, but then it wanted me to define a DLL with 3 functions, so I tried to find a simpler solution.
ezio-melotti commentedon Mar 4, 2013
Attached an updated patch:
I tested it on Windows 7 and Linux (where it's a no-op), and according to MSDN it should work even on Windows XP. If there aren't other comments I'll commit this soon. If test_capi is also crashing on 2.7/3.2, I will probably backport it there too.
python-dev commentedon Mar 5, 2013
New changeset 834a451f1cdb by Ezio Melotti in branch '3.3':
bpo-11732: add a new suppress_crash_popup() context manager to test.support.
http://hg.python.org/cpython/rev/834a451f1cdb
New changeset b87123015fb0 by Ezio Melotti in branch 'default':
bpo-11732: merge with 3.3.
http://hg.python.org/cpython/rev/b87123015fb0
ezio-melotti commentedon Mar 5, 2013
I applied this only on 3.3/3.x because I didn't manage to test on 2.7/3.2.
If test_ctypes and/or other tests are failing there I can backport it, but the patch needs to be tweaked there because it doesn't apply cleanly (and there's no test_faulthandler there).
ezio-melotti commentedon Mar 6, 2013
Attached an untested patch against 3.2.
On 2.7 and 3.2 there's no test_faulthandler, and the crashing test in test_ctypes seems to be in 3.x only.
Unless I'm missing something:
Brian, if you can confirm this I'll go ahead, backport the patch on 3.2, and null merge it on 3.3/default.
python-dev commentedon Mar 7, 2013
New changeset 6ccefddc13fd by Ezio Melotti in branch '3.3':
bpo-11732: make suppress_crash_popup() work on Windows XP and Windows Server 2003.
http://hg.python.org/cpython/rev/6ccefddc13fd
New changeset 831035bda9b7 by Ezio Melotti in branch 'default':
bpo-11732: merge with 3.3.
http://hg.python.org/cpython/rev/831035bda9b7
python-dev commentedon Mar 7, 2013
New changeset c0c440dcb8dd by Ezio Melotti in branch '3.2':
bpo-11732: add a new suppress_crash_popup() context manager to test.support that disables crash popups on Windows and use it in test_ctypes.
http://hg.python.org/cpython/rev/c0c440dcb8dd
New changeset 89d62bc81e47 by Ezio Melotti in branch '3.3':
bpo-11732: null merge with 3.2.
http://hg.python.org/cpython/rev/89d62bc81e47
New changeset 7e818490d297 by Ezio Melotti in branch 'default':
bpo-11732: null merge with 3.3.
http://hg.python.org/cpython/rev/7e818490d297
ezio-melotti commentedon Mar 7, 2013
GetErrorMode wasn't available on XP/2k3, so I changed the patch to use only SetErrorMode. I also backported it to 3.2, since ctypes has the same crashing test of 3.3/default.
If I got everything right there shouldn't be anymore crash popups while running the tests, however I haven't tested this on 2.7/3.2, so there might be other popups that I missed. If there are, feel free to reopen the issue.
ezio-melotti commentedon Mar 14, 2013
I just noticed that regrtest also has a --nowindows flag that uses SetErrorMode (see Lib/test/regrtest.py:490).
The implementation is a bit different:
Do you think this flag should be removed?
Should I improve my context manager with any of these things?