| msg192566 - (view) |
Author: STINNER Victor (vstinner) *  |
Date: 2013-07-07 14:42 |
| ERROR: test_issue9324 (test.test_signal.WindowsSignalTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_signal.py", line 213, in test_issue9324 signal.signal(sig, signal.signal(sig, handler)) TypeError: signal handler must be signal.SIG_IGN, signal.SIG_DFL, or a callable object Related issue: #9324 (closed 3 years ago). |
|
|
| msg192618 - (view) |
Author: Jeremy Kloth (jkloth) * |
Date: 2013-07-08 06:35 |
| This error is reproducible by simply passing '-j' to regrtest on any Windows build so it is not Win64-specific. It seems that when run in a subprocess, certain signals have C handlers that cause the return value of getsignal() to return None which, of course, is not a valid handler for signal(). The C-level handlers seem to be coming from faulthandler so I am unsure if it is wise to replace those signal handlers within the test. Attached is a patch which only resets signal handlers for those without a C-level handler. |
|
|
| msg193855 - (view) |
Author: Alyssa Coghlan (ncoghlan) * |
Date: 2013-07-29 07:56 |
| Is it possible this is indicating a real bug with faulthandler on Windows? Why are we returning None from signal.getsignal? |
|
|
| msg193856 - (view) |
Author: Jeremy Kloth (jkloth) * |
Date: 2013-07-29 08:02 |
| It do not think that it is a just a Windows issue wrt faulthandler. It is that there are no similar tests for signals on other platforms. getsignal() needs to return *something* for the value of a handler which is not SIG_DFL or SIG_IGN. |
|
|
| msg193858 - (view) |
Author: Jeremy Kloth (jkloth) * |
Date: 2013-07-29 11:29 |
| Added nosy list from issue 18523 |
|
|
| msg194253 - (view) |
Author: Alyssa Coghlan (ncoghlan) * |
Date: 2013-08-03 12:45 |
| I checked the getsignal docs, and indeed None is the expected return value for "signal handler exists, but was not installed from Python". That's accurate given the way faulthandler works: On Linux (Python 3.3.0): $ python3 -c "import signal; print(signal.getsignal(signal.SIGSEGV))" 0 $ python3 -X faulthandler -c "import signal; print(signal.getsignal(signal.SIGSEGV))" None So Jeremy's patch looks correct to me - when faulthandler is enabled, we need to skip over the signals that have those handlers attached. |
|
|
| msg194255 - (view) |
Author: Roundup Robot (python-dev)  |
Date: 2013-08-03 13:03 |
| New changeset b7834800562f by Nick Coghlan in branch '3.3': Close #18396: fix spurious test_signal failure on Windows http://hg.python.org/cpython/rev/b7834800562f New changeset 6fc71ed6a910 by Nick Coghlan in branch 'default': Merge #18396 from 3.3 http://hg.python.org/cpython/rev/6fc71ed6a910 |
|
|
| msg194256 - (view) |
Author: Alyssa Coghlan (ncoghlan) * |
Date: 2013-08-03 13:05 |
| I added one slight tweak to Jeremy's patch - an assertion to ensure that test loop is checking at least some* signals, even when faulthandler is enabled. |
|
|