Seen on an OpenIndiana buildbot:

======================================================================
FAIL: testInstallHandler (unittest.test.test_break.TestBreak)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/export/home/buildbot/64bits/3.2.cea-indiana-amd64/build/Lib/unittest/test/test_break.py", line 37, in testInstallHandler
    self.assertTrue(unittest.signals._interrupt_handler.called)
AssertionError: False is not true

http://www.python.org/dev/buildbot/all/builders/AMD64%20OpenIndiana%203.2/builds/454/steps/test/logs/stdio


Probably something to do with signals behaviour under that particular OS.

Looks similar to issue #8263, which is in turn similar to #12469 (see
http://bugs.python.org/issue12469#msg139620 and
http://bugs.python.org/issue12469#msg139626 for original explanations):
normally, pending signals are checked when the process returns to
user-space, so a code like:

os.kill(os.getpid(), signum)
self.assertTrue(signum's handler called)

will succeed, because the signal is delivered before the kill()
syscall returns (it's actually required by POSIX), and the Python
signal handler will be called from the main eval loop before the assertion
test.
But if the signal isn't delivered right away (on FreeBSD6, it happens
only after a thread has been created, which explains #12469 and
probably #8263), then this check can fail (the signal will be
delivered typically when the next syscall returns, or at the next
timer interrupt, which could be after the test).

So I'd say the easier solution is to skip this test on OpenSolaris,
like it's done on FreeBSD6 since issue #8263.
Patch attached.

> So I'd say the easier solution is to skip this test on OpenSolaris,
> like it's done on FreeBSD6 since issue #8263.

Another option could be to add a dummy syscall, like os.getpid(),
before checking that the handler got called - this might be enough to
have the signal delivered.
Note that this kind of test assumes that the Python signal handler is
called right after the signal is delivered, i.e. every time from the
main eval loop (I think that's true with recent Python versions, is
that true with 2.7?).

> Note that this kind of test assumes that the Python signal handler is
> called right after the signal is delivered, i.e. every time from the
> main eval loop (I think that's true with recent Python versions, is
> that true with 2.7?).

No, it's a feature of the new GIL.

> No, it's a feature of the new GIL.

When I look at 2.7's code, I see something different - _Py_Ticker is
reset in Py_AddPendingCall():

int
Py_AddPendingCall(int (*func)(void *), void *arg)
{
[...]
    /* signal main loop */
    _Py_Ticker = 0;
    pendingcalls_to_do = 1;
[...]
}

And there's a comment in the main eval loop which confirms this:
        /* Do periodic things.  Doing this every time through
           the loop would add too much overhead, so we do it
           only every Nth instruction.  We also do it if
           ``pendingcalls_to_do'' is set, i.e. when an asynchronous
           event needs attention (e.g. a signal handler or
           async I/O handler); see Py_AddPendingCall() and
           Py_MakePendingCalls() above. */

So, AFAICT, signal handlers will get called right away (and if I
remove the _Py_Ticker reset from Py_AddPendingCall(), then those tests
fail consistently on Linux).
Or am I missing something?

Concerning the original problem, here's a patch implementing the second idea:
- getpid() is called after each kill(getpid(), <signum>), to "force"
the signal delivery
- the test is now re-enabled on FreeBSD6

I think this should fx the problem on both FreeBSD6 and OpenSolaris,
but since I don't have a FreeBSD or OpenSolaris box at hand, I
couldn't test it. Shall I try to commit it and see what the buildbots
say?

> getpid() is called after each kill(getpid(), <signum>),
> to "force" the signal delivery

Please write a function (in test.support?) with a comment explaining why you are doing that.

You may also only do this workaround on specific platforms. For example, only on FreeBSD and OpenIndiana (the test would be in the function).

> Please write a function (in test.support?) with a comment explaining why you
> are doing that.
> You may also only do this workaround on specific platforms. For example,
> only on FreeBSD and OpenIndiana (the test would be in the function).

There's already a comment right before the first call to getpid(). I
thought about making it a function, but since it's such a kludge, it
dropped the idea. I don't mind making it a function, though.
As for calling this only on specific platforms, well, I don't know
exactly which platforms are affected, so I stayed on the safe side
(for example, is FreeBSD4 affected?).

But I'd like first to make sure this works. IIRC, you have access to a
FreeBSD6 box. Could you test it there and see if it works?

I promise, I'll soon setup a clone to be able to test my patches on
the buildbot. I just have to select "Server-side clone" on
http://hg.python.org/cpython/# ?

Can this be closed as "out of date"?

Is this test still failing? Or can this be closed?

> Is this test still failing? Or can this be closed?

The OpenIndiana buildbot is gone for many years. See also bpo-42173.