Nick Coghlan added the comment:
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;
Roundup Robot added the comment:
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
Nick Coghlan added the comment:
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.
--
___
Python tracker rep...@bugs.python.org
Nick Coghlan added the comment:
Is it possible this is indicating a real bug with faulthandler on Windows? Why
are we returning None from signal.getsignal?
--
nosy: +ncoghlan
___
Python tracker rep...@bugs.python.org
Jeremy Kloth added the comment:
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.
--
Jeremy Kloth added the comment:
Added nosy list from issue 18523
--
nosy: +brian.curtin, larry, pitrou
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18396
___
Jeremy Kloth added the comment:
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,
New submission from STINNER Victor:
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
