Skip to content

Skip decorator for tests requiring manual intervention on Windows #55941

Closed

Description

@briancurtin
BPO 11732
Nosy @loewis, @terryjreedy, @vstinner, @ezio-melotti, @briancurtin, @skrah
Files
  • unattended_decorator.diff
  • faulthandler_example.diff
  • nopopup.diff
  • nopopup2.diff
  • nopopup3.2.diff: Patch for 3.2.
  • Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

    Show more details

    GitHub fields:

    assignee = 'https://github.com/ezio-melotti'
    closed_at = <Date 2013-03-05.19:04:41.712>
    created_at = <Date 2011-03-31.20:53:28.214>
    labels = ['type-bug', 'tests', 'OS-windows']
    title = 'Skip decorator for tests requiring manual intervention on Windows'
    updated_at = <Date 2013-03-14.01:21:25.860>
    user = 'https://github.com/briancurtin'

    bugs.python.org fields:

    activity = <Date 2013-03-14.01:21:25.860>
    actor = 'ezio.melotti'
    assignee = 'ezio.melotti'
    closed = True
    closed_date = <Date 2013-03-05.19:04:41.712>
    closer = 'ezio.melotti'
    components = ['Tests', 'Windows']
    creation = <Date 2011-03-31.20:53:28.214>
    creator = 'brian.curtin'
    dependencies = []
    files = ['21493', '21494', '29130', '29309', '29320']
    hgrepos = []
    issue_num = 11732
    keywords = ['patch']
    message_count = 21.0
    messages = ['132699', '132700', '132704', '132706', '133140', '139705', '139706', '139707', '139708', '139710', '148454', '148455', '182474', '183504', '183540', '183547', '183572', '183681', '183683', '183685', '184123']
    nosy_count = 9.0
    nosy_names = ['loewis', 'terry.reedy', 'vstinner', 'sable', 'ezio.melotti', 'brian.curtin', 'skrah', 'catalin.iacob', 'python-dev']
    pr_nums = []
    priority = 'normal'
    resolution = 'fixed'
    stage = 'resolved'
    status = 'closed'
    superseder = None
    type = 'behavior'
    url = 'https://bugs.python.org/issue11732'
    versions = ['Python 3.2', 'Python 3.3', 'Python 3.4']

    Activity

    1. briancurtin commented on Mar 31, 2011

      @briancurtin
      MemberAuthor

      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

    2. self-assigned this
      on Mar 31, 2011
    3. briancurtin commented on Mar 31, 2011

      @briancurtin
      MemberAuthor

      Attached is an example of how this might be used with Lib/test/test_faulthandler.py

    4. vstinner commented on Mar 31, 2011

      @vstinner
      Member

      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 :-(

    5. vstinner commented on Mar 31, 2011

      @vstinner
      Member

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

    6. briancurtin commented on Apr 6, 2011

      @briancurtin
      MemberAuthor

      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.

    7. vstinner commented on Jul 3, 2011

      @vstinner
      Member

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

    8. vstinner commented on Jul 3, 2011

      @vstinner
      Member

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

    9. skrah commented on Jul 3, 2011

      skrahmannequin
      Mannequin

      For test_capi the patch in bpo-9116 works. For test_faulthandler it
      doesn't, unfortunately.

    10. skrah commented on Jul 3, 2011

      skrahmannequin
      Mannequin

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

    11. vstinner commented on Jul 3, 2011

      @vstinner
      Member

      Do you mean that the user should change/restore the key
      or that the Python tests should do that?

      Python can change temporary the registry value for the duration of the test.

    12. cataliniacob commented on Nov 27, 2011

      cataliniacobmannequin
      Mannequin

      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.

    13. briancurtin commented on Nov 27, 2011

      @briancurtin
      MemberAuthor

      That would certainly be preferable when available on Windows 7. I'll look into how we can incorporate that.

      Thanks for the idea!

    14. ezio-melotti commented on Feb 20, 2013

      @ezio-melotti
      Member

      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.

    15. ezio-melotti commented on Mar 4, 2013

      @ezio-melotti
      Member

      Attached an updated patch:

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

    16. python-dev commented on Mar 5, 2013

      python-devmannequin
      Mannequin

      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

    17. ezio-melotti commented on Mar 5, 2013

      @ezio-melotti
      Member

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

    18. ezio-melotti commented on Mar 6, 2013

      @ezio-melotti
      Member

      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:

      1. no crash popups should appear while running the 2.7 test suite;
      2. only test_ctypes should show a crash popup on 3.2 and the attached patch should fix it;

      Brian, if you can confirm this I'll go ahead, backport the patch on 3.2, and null merge it on 3.3/default.

    19. python-dev commented on Mar 7, 2013

      python-devmannequin
      Mannequin

      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

    20. python-dev commented on Mar 7, 2013

      python-devmannequin
      Mannequin

      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

    21. ezio-melotti commented on Mar 7, 2013

      @ezio-melotti
      Member

      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.

    22. ezio-melotti commented on Mar 14, 2013

      @ezio-melotti
      Member

      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:

      1. it uses msvcrt instead of going through ctypes.windll.kernel32;
      2. it specifies SEM_FAILCRITICALERRORS, SEM_NOALIGNMENTFAULTEXCEPT, and SEM_NOOPENFILEERRORBOX in addition to SEM_NOGPFAULTERRORBOX;
      3. it doesn's seem to save and restore the previous error mode;
      4. it has additional calls to CrtSetReportMode and CrtSetReportFile;
      5. it doesn't check the platform and thus raises an ImportError if msvcrt is missing;

      Do you think this flag should be removed?
      Should I improve my context manager with any of these things?

    23. transferred this issue fromon Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

    Metadata

    Metadata

    Assignees

    Labels

    OS-windowstestsTests in the Lib/test dirtype-bugAn unexpected behavior, bug, or error

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions