[issue12625] sporadic test_unittest failure

[STINNER Victor]

STINNER Victor  added the comment:

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

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

--
resolution:  -> out of date
stage:  -> resolved
status: pending -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12625] sporadic test_unittest failure

[Irit Katriel]

Irit Katriel  added the comment:

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

--
nosy: +iritkatriel
status: open -> pending

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12625] sporadic test_unittest failure

[Mark Lawrence]

Change by Mark Lawrence :


--
nosy:  -BreamoreBoy

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12625] sporadic test_unittest failure

[Mark Lawrence]

Mark Lawrence added the comment:

Can this be closed as out of date?

--
nosy: +BreamoreBoy

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12625
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12625] sporadic test_unittest failure

[STINNER Victor]

STINNER Victor victor.stin...@haypocalc.com added the comment:

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

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12625
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12625] sporadic test_unittest failure

[Charles-François Natali]

Charles-François Natali neolo...@free.fr added the comment:

 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/# ?

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12625
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12625] sporadic test_unittest failure

[Charles-François Natali]

Charles-François Natali neolo...@free.fr added the comment:

 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?

--
Added file: http://bugs.python.org/file22743/kill_delayed_signal.diff

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12625
___diff -r cda93720c06d Lib/unittest/test/test_break.py
--- a/Lib/unittest/test/test_break.py   Sat Jul 23 18:15:43 2011 +0200
+++ b/Lib/unittest/test/test_break.py   Sun Jul 24 14:23:32 2011 +0200
@@ -10,8 +10,6 @@
 
 @unittest.skipUnless(hasattr(os, 'kill'), Test requires os.kill)
 @unittest.skipIf(sys.platform ==win32, Test cannot run on Windows)
-@unittest.skipIf(sys.platform == 'freebsd6', Test kills regrtest on freebsd6 
-if threads have been used)
 class TestBreak(unittest.TestCase):
 
 def setUp(self):
@@ -29,8 +27,15 @@
 self.assertNotEqual(signal.getsignal(signal.SIGINT), default_handler)
 
 try:
+# When a process sends a signal to itself, POSIX states that the
+# signal must be delivered before the kill() syscall returns. Some
+# operating systems are known to delay signal delivery in this
+# situation (see issues #12625, #8263 and #12469): to force the
+# signal's delivery, we make a dummy getpid() syscall (signals are
+# typically delivered when the process returns to user-space).
 pid = os.getpid()
 os.kill(pid, signal.SIGINT)
+os.getpid()
 except KeyboardInterrupt:
 self.fail(KeyboardInterrupt not handled)
 
@@ -61,6 +66,7 @@
 def test(result):
 pid = os.getpid()
 os.kill(pid, signal.SIGINT)
+os.getpid()
 result.breakCaught = True
 self.assertTrue(result.shouldStop)
 
@@ -79,9 +85,11 @@
 def test(result):
 pid = os.getpid()
 os.kill(pid, signal.SIGINT)
+os.getpid()
 result.breakCaught = True
 self.assertTrue(result.shouldStop)
 os.kill(pid, signal.SIGINT)
+os.getpid()
 self.fail(Second KeyboardInterrupt not raised)
 
 try:
@@ -109,6 +117,7 @@
 def test(result):
 pid = os.getpid()
 os.kill(pid, signal.SIGINT)
+os.getpid()
 
 try:
 test(result)
@@ -134,6 +143,7 @@
 try:
 pid = os.getpid()
 os.kill(pid, signal.SIGINT)
+os.getpid()
 except KeyboardInterrupt:
 pass
 else:
@@ -173,6 +183,7 @@
 try:
 pid = os.getpid()
 os.kill(pid, signal.SIGINT)
+os.getpid()
 except KeyboardInterrupt:
 pass
 
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12625] sporadic test_unittest failure

[Antoine Pitrou]

New submission from Antoine Pitrou pit...@free.fr:

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.

--
components: Library (Lib), Tests
messages: 141019
nosy: haypo, michael.foord, neologix, pitrou
priority: normal
severity: normal
status: open
title: sporadic test_unittest failure
type: behavior
versions: Python 3.2, Python 3.3

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12625
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12625] sporadic test_unittest failure

[Charles-François Natali]

Charles-François Natali neolo...@free.fr added the comment:

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.

--
keywords: +patch
Added file: http://bugs.python.org/file22736/indiana_signal.diff

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12625
___diff -r cda93720c06d Lib/unittest/test/test_break.py
--- a/Lib/unittest/test/test_break.py   Sat Jul 23 18:15:43 2011 +0200
+++ b/Lib/unittest/test/test_break.py   Sun Jul 24 00:57:04 2011 +0200
@@ -9,9 +9,9 @@
 
 
 @unittest.skipUnless(hasattr(os, 'kill'), Test requires os.kill)
-@unittest.skipIf(sys.platform ==win32, Test cannot run on Windows)
-@unittest.skipIf(sys.platform == 'freebsd6', Test kills regrtest on freebsd6 
-if threads have been used)
+@unittest.skipIf(sys.platform == 'win32', Test cannot run on Windows)
+@unittest.skipIf(sys.platform == 'freebsd6', due to known OS bug)
+@unittest.skipIf(sys.platform.startswith('sunos'), due to known OS bug)
 class TestBreak(unittest.TestCase):
 
 def setUp(self):
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12625] sporadic test_unittest failure

[Charles-François Natali]

Charles-François Natali neolo...@free.fr added the comment:

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

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12625
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12625] sporadic test_unittest failure

[Antoine Pitrou]

Antoine Pitrou pit...@free.fr added the comment:

 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.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12625
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com