1995-03-16 11:07:38 -04:00
|
|
|
# Test the signal module
|
2006-01-23 03:50:06 -04:00
|
|
|
from test.test_support import verbose, TestSkipped, TestFailed, vereq
|
1995-03-16 11:07:38 -04:00
|
|
|
import signal
|
2002-05-27 12:08:24 -03:00
|
|
|
import os, sys, time
|
1997-04-15 21:29:15 -03:00
|
|
|
|
2001-10-24 17:42:55 -03:00
|
|
|
if sys.platform[:3] in ('win', 'os2') or sys.platform=='riscos':
|
|
|
|
raise TestSkipped, "Can't test signal on %s" % sys.platform
|
1995-03-16 11:07:38 -04:00
|
|
|
|
test_signal: Signal handling on the Tru64 buildbot
appears to be utterly insane. Plug some theoretical
insecurities in the test script:
- Verify that the SIGALRM handler was actually installed.
- Don't call alarm() before the handler is installed.
- Move everything that can fail inside the try/finally,
so the test cleans up after itself more often.
- Try sending all the expected signals in
force_test_exit(), not just SIGALRM. Since that was
fixed to actually send SIGALRM (instead of invisibly
dying with an AttributeError), we've seen that sending
SIGALRM alone does not stop this from hanging.
- Move the "kill the child" business into the finally
clause, so the child doesn't survive test failure
to send SIGALRM to other tests later (there are also
baffling SIGALRM-related failures in test_socket).
- Cancel the alarm in the finally clause -- if the
test dies early, we again don't want SIGALRM showing
up to confuse a later test.
Alas, this still relies on timing luck wrt the spawned
script that sends the test signals, but it's hard to see
how waiting for seconds can so often be so unlucky.
test_threadedsignals: curiously, this test never fails
on Tru64, but doesn't normally signal SIGALRM. Anyway,
fixed an obvious (but probably inconsequential) logic
error.
2006-08-12 01:42:47 -03:00
|
|
|
MAX_DURATION = 20 # Entire test should last at most 20 sec.
|
|
|
|
|
1996-12-23 19:39:42 -04:00
|
|
|
if verbose:
|
2000-10-23 14:22:08 -03:00
|
|
|
x = '-x'
|
1996-12-23 19:39:42 -04:00
|
|
|
else:
|
2000-10-23 14:22:08 -03:00
|
|
|
x = '+x'
|
2006-08-11 00:49:10 -03:00
|
|
|
|
1995-03-16 11:07:38 -04:00
|
|
|
pid = os.getpid()
|
2006-08-11 00:49:10 -03:00
|
|
|
if verbose:
|
|
|
|
print "test runner's pid is", pid
|
1995-03-16 11:07:38 -04:00
|
|
|
|
|
|
|
# Shell script that will send us asynchronous signals
|
|
|
|
script = """
|
1996-12-23 19:39:42 -04:00
|
|
|
(
|
2000-10-23 14:22:08 -03:00
|
|
|
set %(x)s
|
|
|
|
sleep 2
|
2004-06-11 15:09:28 -03:00
|
|
|
kill -HUP %(pid)d
|
2000-10-23 14:22:08 -03:00
|
|
|
sleep 2
|
2004-06-11 15:09:28 -03:00
|
|
|
kill -USR1 %(pid)d
|
2000-10-23 14:22:08 -03:00
|
|
|
sleep 2
|
2004-06-11 15:09:28 -03:00
|
|
|
kill -USR2 %(pid)d
|
1996-12-23 19:39:42 -04:00
|
|
|
) &
|
1995-03-16 11:07:38 -04:00
|
|
|
""" % vars()
|
|
|
|
|
2006-07-30 16:18:38 -03:00
|
|
|
a_called = b_called = False
|
|
|
|
|
1995-03-16 11:07:38 -04:00
|
|
|
def handlerA(*args):
|
2006-07-30 16:18:38 -03:00
|
|
|
global a_called
|
|
|
|
a_called = True
|
2000-10-23 14:22:08 -03:00
|
|
|
if verbose:
|
test_signal: Signal handling on the Tru64 buildbot
appears to be utterly insane. Plug some theoretical
insecurities in the test script:
- Verify that the SIGALRM handler was actually installed.
- Don't call alarm() before the handler is installed.
- Move everything that can fail inside the try/finally,
so the test cleans up after itself more often.
- Try sending all the expected signals in
force_test_exit(), not just SIGALRM. Since that was
fixed to actually send SIGALRM (instead of invisibly
dying with an AttributeError), we've seen that sending
SIGALRM alone does not stop this from hanging.
- Move the "kill the child" business into the finally
clause, so the child doesn't survive test failure
to send SIGALRM to other tests later (there are also
baffling SIGALRM-related failures in test_socket).
- Cancel the alarm in the finally clause -- if the
test dies early, we again don't want SIGALRM showing
up to confuse a later test.
Alas, this still relies on timing luck wrt the spawned
script that sends the test signals, but it's hard to see
how waiting for seconds can so often be so unlucky.
test_threadedsignals: curiously, this test never fails
on Tru64, but doesn't normally signal SIGALRM. Anyway,
fixed an obvious (but probably inconsequential) logic
error.
2006-08-12 01:42:47 -03:00
|
|
|
print "handlerA invoked", args
|
1995-03-16 11:07:38 -04:00
|
|
|
|
2004-08-07 18:27:43 -03:00
|
|
|
class HandlerBCalled(Exception):
|
|
|
|
pass
|
1995-03-16 11:07:38 -04:00
|
|
|
|
|
|
|
def handlerB(*args):
|
2006-07-30 16:18:38 -03:00
|
|
|
global b_called
|
|
|
|
b_called = True
|
2000-10-23 14:22:08 -03:00
|
|
|
if verbose:
|
test_signal: Signal handling on the Tru64 buildbot
appears to be utterly insane. Plug some theoretical
insecurities in the test script:
- Verify that the SIGALRM handler was actually installed.
- Don't call alarm() before the handler is installed.
- Move everything that can fail inside the try/finally,
so the test cleans up after itself more often.
- Try sending all the expected signals in
force_test_exit(), not just SIGALRM. Since that was
fixed to actually send SIGALRM (instead of invisibly
dying with an AttributeError), we've seen that sending
SIGALRM alone does not stop this from hanging.
- Move the "kill the child" business into the finally
clause, so the child doesn't survive test failure
to send SIGALRM to other tests later (there are also
baffling SIGALRM-related failures in test_socket).
- Cancel the alarm in the finally clause -- if the
test dies early, we again don't want SIGALRM showing
up to confuse a later test.
Alas, this still relies on timing luck wrt the spawned
script that sends the test signals, but it's hard to see
how waiting for seconds can so often be so unlucky.
test_threadedsignals: curiously, this test never fails
on Tru64, but doesn't normally signal SIGALRM. Anyway,
fixed an obvious (but probably inconsequential) logic
error.
2006-08-12 01:42:47 -03:00
|
|
|
print "handlerB invoked", args
|
2000-10-23 14:22:08 -03:00
|
|
|
raise HandlerBCalled, args
|
1995-03-16 11:07:38 -04:00
|
|
|
|
test_signal: Signal handling on the Tru64 buildbot
appears to be utterly insane. Plug some theoretical
insecurities in the test script:
- Verify that the SIGALRM handler was actually installed.
- Don't call alarm() before the handler is installed.
- Move everything that can fail inside the try/finally,
so the test cleans up after itself more often.
- Try sending all the expected signals in
force_test_exit(), not just SIGALRM. Since that was
fixed to actually send SIGALRM (instead of invisibly
dying with an AttributeError), we've seen that sending
SIGALRM alone does not stop this from hanging.
- Move the "kill the child" business into the finally
clause, so the child doesn't survive test failure
to send SIGALRM to other tests later (there are also
baffling SIGALRM-related failures in test_socket).
- Cancel the alarm in the finally clause -- if the
test dies early, we again don't want SIGALRM showing
up to confuse a later test.
Alas, this still relies on timing luck wrt the spawned
script that sends the test signals, but it's hard to see
how waiting for seconds can so often be so unlucky.
test_threadedsignals: curiously, this test never fails
on Tru64, but doesn't normally signal SIGALRM. Anyway,
fixed an obvious (but probably inconsequential) logic
error.
2006-08-12 01:42:47 -03:00
|
|
|
# Set up a child to send signals to us (the parent) after waiting long
|
|
|
|
# enough to receive the alarm. It seems we miss the alarm for some
|
|
|
|
# reason. This will hopefully stop the hangs on Tru64/Alpha.
|
|
|
|
# Alas, it doesn't. Tru64 appears to miss all the signals at times, or
|
|
|
|
# seemingly random subsets of them, and nothing done in force_test_exit
|
|
|
|
# so far has actually helped.
|
|
|
|
def force_test_exit():
|
|
|
|
# Sigh, both imports seem necessary to avoid errors.
|
|
|
|
import os
|
|
|
|
fork_pid = os.fork()
|
|
|
|
if fork_pid:
|
|
|
|
# In parent.
|
|
|
|
return fork_pid
|
|
|
|
|
|
|
|
# In child.
|
|
|
|
import os, time
|
|
|
|
try:
|
|
|
|
# Wait 5 seconds longer than the expected alarm to give enough
|
|
|
|
# time for the normal sequence of events to occur. This is
|
|
|
|
# just a stop-gap to try to prevent the test from hanging.
|
|
|
|
time.sleep(MAX_DURATION + 5)
|
|
|
|
print >> sys.__stdout__, ' child should not have to kill parent'
|
|
|
|
for signame in "SIGHUP", "SIGUSR1", "SIGUSR2", "SIGALRM":
|
|
|
|
os.kill(pid, getattr(signal, signame))
|
|
|
|
print >> sys.__stdout__, " child sent", signame, "to", pid
|
|
|
|
time.sleep(1)
|
|
|
|
finally:
|
|
|
|
os._exit(0)
|
|
|
|
|
|
|
|
# Install handlers.
|
2004-06-11 15:09:28 -03:00
|
|
|
hup = signal.signal(signal.SIGHUP, handlerA)
|
|
|
|
usr1 = signal.signal(signal.SIGUSR1, handlerB)
|
|
|
|
usr2 = signal.signal(signal.SIGUSR2, signal.SIG_IGN)
|
|
|
|
alrm = signal.signal(signal.SIGALRM, signal.default_int_handler)
|
1995-03-16 11:07:38 -04:00
|
|
|
|
2006-01-23 03:50:06 -04:00
|
|
|
try:
|
|
|
|
|
test_signal: Signal handling on the Tru64 buildbot
appears to be utterly insane. Plug some theoretical
insecurities in the test script:
- Verify that the SIGALRM handler was actually installed.
- Don't call alarm() before the handler is installed.
- Move everything that can fail inside the try/finally,
so the test cleans up after itself more often.
- Try sending all the expected signals in
force_test_exit(), not just SIGALRM. Since that was
fixed to actually send SIGALRM (instead of invisibly
dying with an AttributeError), we've seen that sending
SIGALRM alone does not stop this from hanging.
- Move the "kill the child" business into the finally
clause, so the child doesn't survive test failure
to send SIGALRM to other tests later (there are also
baffling SIGALRM-related failures in test_socket).
- Cancel the alarm in the finally clause -- if the
test dies early, we again don't want SIGALRM showing
up to confuse a later test.
Alas, this still relies on timing luck wrt the spawned
script that sends the test signals, but it's hard to see
how waiting for seconds can so often be so unlucky.
test_threadedsignals: curiously, this test never fails
on Tru64, but doesn't normally signal SIGALRM. Anyway,
fixed an obvious (but probably inconsequential) logic
error.
2006-08-12 01:42:47 -03:00
|
|
|
signal.alarm(MAX_DURATION)
|
|
|
|
vereq(signal.getsignal(signal.SIGHUP), handlerA)
|
|
|
|
vereq(signal.getsignal(signal.SIGUSR1), handlerB)
|
|
|
|
vereq(signal.getsignal(signal.SIGUSR2), signal.SIG_IGN)
|
|
|
|
vereq(signal.getsignal(signal.SIGALRM), signal.default_int_handler)
|
2006-01-23 03:50:06 -04:00
|
|
|
|
test_signal: Signal handling on the Tru64 buildbot
appears to be utterly insane. Plug some theoretical
insecurities in the test script:
- Verify that the SIGALRM handler was actually installed.
- Don't call alarm() before the handler is installed.
- Move everything that can fail inside the try/finally,
so the test cleans up after itself more often.
- Try sending all the expected signals in
force_test_exit(), not just SIGALRM. Since that was
fixed to actually send SIGALRM (instead of invisibly
dying with an AttributeError), we've seen that sending
SIGALRM alone does not stop this from hanging.
- Move the "kill the child" business into the finally
clause, so the child doesn't survive test failure
to send SIGALRM to other tests later (there are also
baffling SIGALRM-related failures in test_socket).
- Cancel the alarm in the finally clause -- if the
test dies early, we again don't want SIGALRM showing
up to confuse a later test.
Alas, this still relies on timing luck wrt the spawned
script that sends the test signals, but it's hard to see
how waiting for seconds can so often be so unlucky.
test_threadedsignals: curiously, this test never fails
on Tru64, but doesn't normally signal SIGALRM. Anyway,
fixed an obvious (but probably inconsequential) logic
error.
2006-08-12 01:42:47 -03:00
|
|
|
# Try to ensure this test exits even if there is some problem with alarm.
|
|
|
|
# Tru64/Alpha often hangs and is ultimately killed by the buildbot.
|
|
|
|
fork_pid = force_test_exit()
|
2006-01-23 03:50:06 -04:00
|
|
|
|
test_signal: Signal handling on the Tru64 buildbot
appears to be utterly insane. Plug some theoretical
insecurities in the test script:
- Verify that the SIGALRM handler was actually installed.
- Don't call alarm() before the handler is installed.
- Move everything that can fail inside the try/finally,
so the test cleans up after itself more often.
- Try sending all the expected signals in
force_test_exit(), not just SIGALRM. Since that was
fixed to actually send SIGALRM (instead of invisibly
dying with an AttributeError), we've seen that sending
SIGALRM alone does not stop this from hanging.
- Move the "kill the child" business into the finally
clause, so the child doesn't survive test failure
to send SIGALRM to other tests later (there are also
baffling SIGALRM-related failures in test_socket).
- Cancel the alarm in the finally clause -- if the
test dies early, we again don't want SIGALRM showing
up to confuse a later test.
Alas, this still relies on timing luck wrt the spawned
script that sends the test signals, but it's hard to see
how waiting for seconds can so often be so unlucky.
test_threadedsignals: curiously, this test never fails
on Tru64, but doesn't normally signal SIGALRM. Anyway,
fixed an obvious (but probably inconsequential) logic
error.
2006-08-12 01:42:47 -03:00
|
|
|
try:
|
|
|
|
signal.getsignal(4242)
|
|
|
|
raise TestFailed('expected ValueError for invalid signal # to '
|
|
|
|
'getsignal()')
|
|
|
|
except ValueError:
|
|
|
|
pass
|
2006-07-30 16:20:42 -03:00
|
|
|
|
test_signal: Signal handling on the Tru64 buildbot
appears to be utterly insane. Plug some theoretical
insecurities in the test script:
- Verify that the SIGALRM handler was actually installed.
- Don't call alarm() before the handler is installed.
- Move everything that can fail inside the try/finally,
so the test cleans up after itself more often.
- Try sending all the expected signals in
force_test_exit(), not just SIGALRM. Since that was
fixed to actually send SIGALRM (instead of invisibly
dying with an AttributeError), we've seen that sending
SIGALRM alone does not stop this from hanging.
- Move the "kill the child" business into the finally
clause, so the child doesn't survive test failure
to send SIGALRM to other tests later (there are also
baffling SIGALRM-related failures in test_socket).
- Cancel the alarm in the finally clause -- if the
test dies early, we again don't want SIGALRM showing
up to confuse a later test.
Alas, this still relies on timing luck wrt the spawned
script that sends the test signals, but it's hard to see
how waiting for seconds can so often be so unlucky.
test_threadedsignals: curiously, this test never fails
on Tru64, but doesn't normally signal SIGALRM. Anyway,
fixed an obvious (but probably inconsequential) logic
error.
2006-08-12 01:42:47 -03:00
|
|
|
try:
|
|
|
|
signal.signal(4242, handlerB)
|
|
|
|
raise TestFailed('expected ValueError for invalid signal # to '
|
|
|
|
'signal()')
|
|
|
|
except ValueError:
|
|
|
|
pass
|
1995-03-16 11:07:38 -04:00
|
|
|
|
test_signal: Signal handling on the Tru64 buildbot
appears to be utterly insane. Plug some theoretical
insecurities in the test script:
- Verify that the SIGALRM handler was actually installed.
- Don't call alarm() before the handler is installed.
- Move everything that can fail inside the try/finally,
so the test cleans up after itself more often.
- Try sending all the expected signals in
force_test_exit(), not just SIGALRM. Since that was
fixed to actually send SIGALRM (instead of invisibly
dying with an AttributeError), we've seen that sending
SIGALRM alone does not stop this from hanging.
- Move the "kill the child" business into the finally
clause, so the child doesn't survive test failure
to send SIGALRM to other tests later (there are also
baffling SIGALRM-related failures in test_socket).
- Cancel the alarm in the finally clause -- if the
test dies early, we again don't want SIGALRM showing
up to confuse a later test.
Alas, this still relies on timing luck wrt the spawned
script that sends the test signals, but it's hard to see
how waiting for seconds can so often be so unlucky.
test_threadedsignals: curiously, this test never fails
on Tru64, but doesn't normally signal SIGALRM. Anyway,
fixed an obvious (but probably inconsequential) logic
error.
2006-08-12 01:42:47 -03:00
|
|
|
try:
|
|
|
|
signal.signal(signal.SIGUSR1, None)
|
|
|
|
raise TestFailed('expected TypeError for non-callable')
|
|
|
|
except TypeError:
|
|
|
|
pass
|
1995-03-16 11:07:38 -04:00
|
|
|
|
test_signal: Signal handling on the Tru64 buildbot
appears to be utterly insane. Plug some theoretical
insecurities in the test script:
- Verify that the SIGALRM handler was actually installed.
- Don't call alarm() before the handler is installed.
- Move everything that can fail inside the try/finally,
so the test cleans up after itself more often.
- Try sending all the expected signals in
force_test_exit(), not just SIGALRM. Since that was
fixed to actually send SIGALRM (instead of invisibly
dying with an AttributeError), we've seen that sending
SIGALRM alone does not stop this from hanging.
- Move the "kill the child" business into the finally
clause, so the child doesn't survive test failure
to send SIGALRM to other tests later (there are also
baffling SIGALRM-related failures in test_socket).
- Cancel the alarm in the finally clause -- if the
test dies early, we again don't want SIGALRM showing
up to confuse a later test.
Alas, this still relies on timing luck wrt the spawned
script that sends the test signals, but it's hard to see
how waiting for seconds can so often be so unlucky.
test_threadedsignals: curiously, this test never fails
on Tru64, but doesn't normally signal SIGALRM. Anyway,
fixed an obvious (but probably inconsequential) logic
error.
2006-08-12 01:42:47 -03:00
|
|
|
# Launch an external script to send us signals.
|
|
|
|
# We expect the external script to:
|
|
|
|
# send HUP, which invokes handlerA to set a_called
|
|
|
|
# send USR1, which invokes handlerB to set b_called and raise
|
|
|
|
# HandlerBCalled
|
|
|
|
# send USR2, which is ignored
|
|
|
|
#
|
|
|
|
# Then we expect the alarm to go off, and its handler raises
|
|
|
|
# KeyboardInterrupt, finally getting us out of the loop.
|
|
|
|
os.system(script)
|
2004-06-11 15:09:28 -03:00
|
|
|
try:
|
2006-08-12 02:17:41 -03:00
|
|
|
print "starting pause() loop..."
|
2004-06-11 15:09:28 -03:00
|
|
|
while 1:
|
|
|
|
try:
|
test_signal: Signal handling on the Tru64 buildbot
appears to be utterly insane. Plug some theoretical
insecurities in the test script:
- Verify that the SIGALRM handler was actually installed.
- Don't call alarm() before the handler is installed.
- Move everything that can fail inside the try/finally,
so the test cleans up after itself more often.
- Try sending all the expected signals in
force_test_exit(), not just SIGALRM. Since that was
fixed to actually send SIGALRM (instead of invisibly
dying with an AttributeError), we've seen that sending
SIGALRM alone does not stop this from hanging.
- Move the "kill the child" business into the finally
clause, so the child doesn't survive test failure
to send SIGALRM to other tests later (there are also
baffling SIGALRM-related failures in test_socket).
- Cancel the alarm in the finally clause -- if the
test dies early, we again don't want SIGALRM showing
up to confuse a later test.
Alas, this still relies on timing luck wrt the spawned
script that sends the test signals, but it's hard to see
how waiting for seconds can so often be so unlucky.
test_threadedsignals: curiously, this test never fails
on Tru64, but doesn't normally signal SIGALRM. Anyway,
fixed an obvious (but probably inconsequential) logic
error.
2006-08-12 01:42:47 -03:00
|
|
|
if verbose:
|
|
|
|
print "call pause()..."
|
2004-06-11 15:09:28 -03:00
|
|
|
signal.pause()
|
|
|
|
if verbose:
|
|
|
|
print "pause() returned"
|
|
|
|
except HandlerBCalled:
|
|
|
|
if verbose:
|
|
|
|
print "HandlerBCalled exception caught"
|
2000-10-23 14:22:08 -03:00
|
|
|
|
2004-06-11 15:09:28 -03:00
|
|
|
except KeyboardInterrupt:
|
|
|
|
if verbose:
|
test_signal: Signal handling on the Tru64 buildbot
appears to be utterly insane. Plug some theoretical
insecurities in the test script:
- Verify that the SIGALRM handler was actually installed.
- Don't call alarm() before the handler is installed.
- Move everything that can fail inside the try/finally,
so the test cleans up after itself more often.
- Try sending all the expected signals in
force_test_exit(), not just SIGALRM. Since that was
fixed to actually send SIGALRM (instead of invisibly
dying with an AttributeError), we've seen that sending
SIGALRM alone does not stop this from hanging.
- Move the "kill the child" business into the finally
clause, so the child doesn't survive test failure
to send SIGALRM to other tests later (there are also
baffling SIGALRM-related failures in test_socket).
- Cancel the alarm in the finally clause -- if the
test dies early, we again don't want SIGALRM showing
up to confuse a later test.
Alas, this still relies on timing luck wrt the spawned
script that sends the test signals, but it's hard to see
how waiting for seconds can so often be so unlucky.
test_threadedsignals: curiously, this test never fails
on Tru64, but doesn't normally signal SIGALRM. Anyway,
fixed an obvious (but probably inconsequential) logic
error.
2006-08-12 01:42:47 -03:00
|
|
|
print "KeyboardInterrupt (the alarm() went off)"
|
|
|
|
|
|
|
|
if not a_called:
|
|
|
|
print 'HandlerA not called'
|
|
|
|
|
|
|
|
if not b_called:
|
|
|
|
print 'HandlerB not called'
|
2004-06-11 15:09:28 -03:00
|
|
|
|
test_signal: Signal handling on the Tru64 buildbot
appears to be utterly insane. Plug some theoretical
insecurities in the test script:
- Verify that the SIGALRM handler was actually installed.
- Don't call alarm() before the handler is installed.
- Move everything that can fail inside the try/finally,
so the test cleans up after itself more often.
- Try sending all the expected signals in
force_test_exit(), not just SIGALRM. Since that was
fixed to actually send SIGALRM (instead of invisibly
dying with an AttributeError), we've seen that sending
SIGALRM alone does not stop this from hanging.
- Move the "kill the child" business into the finally
clause, so the child doesn't survive test failure
to send SIGALRM to other tests later (there are also
baffling SIGALRM-related failures in test_socket).
- Cancel the alarm in the finally clause -- if the
test dies early, we again don't want SIGALRM showing
up to confuse a later test.
Alas, this still relies on timing luck wrt the spawned
script that sends the test signals, but it's hard to see
how waiting for seconds can so often be so unlucky.
test_threadedsignals: curiously, this test never fails
on Tru64, but doesn't normally signal SIGALRM. Anyway,
fixed an obvious (but probably inconsequential) logic
error.
2006-08-12 01:42:47 -03:00
|
|
|
finally:
|
2006-07-30 16:20:42 -03:00
|
|
|
# Forcibly kill the child we created to ping us if there was a test error.
|
|
|
|
try:
|
|
|
|
# Make sure we don't kill ourself if there was a fork error.
|
|
|
|
if fork_pid > 0:
|
|
|
|
os.kill(fork_pid, signal.SIGKILL)
|
|
|
|
except:
|
|
|
|
# If the child killed us, it has probably exited. Killing a
|
test_signal: Signal handling on the Tru64 buildbot
appears to be utterly insane. Plug some theoretical
insecurities in the test script:
- Verify that the SIGALRM handler was actually installed.
- Don't call alarm() before the handler is installed.
- Move everything that can fail inside the try/finally,
so the test cleans up after itself more often.
- Try sending all the expected signals in
force_test_exit(), not just SIGALRM. Since that was
fixed to actually send SIGALRM (instead of invisibly
dying with an AttributeError), we've seen that sending
SIGALRM alone does not stop this from hanging.
- Move the "kill the child" business into the finally
clause, so the child doesn't survive test failure
to send SIGALRM to other tests later (there are also
baffling SIGALRM-related failures in test_socket).
- Cancel the alarm in the finally clause -- if the
test dies early, we again don't want SIGALRM showing
up to confuse a later test.
Alas, this still relies on timing luck wrt the spawned
script that sends the test signals, but it's hard to see
how waiting for seconds can so often be so unlucky.
test_threadedsignals: curiously, this test never fails
on Tru64, but doesn't normally signal SIGALRM. Anyway,
fixed an obvious (but probably inconsequential) logic
error.
2006-08-12 01:42:47 -03:00
|
|
|
# non-existent process will raise an error which we don't care about.
|
2006-07-30 16:20:42 -03:00
|
|
|
pass
|
|
|
|
|
test_signal: Signal handling on the Tru64 buildbot
appears to be utterly insane. Plug some theoretical
insecurities in the test script:
- Verify that the SIGALRM handler was actually installed.
- Don't call alarm() before the handler is installed.
- Move everything that can fail inside the try/finally,
so the test cleans up after itself more often.
- Try sending all the expected signals in
force_test_exit(), not just SIGALRM. Since that was
fixed to actually send SIGALRM (instead of invisibly
dying with an AttributeError), we've seen that sending
SIGALRM alone does not stop this from hanging.
- Move the "kill the child" business into the finally
clause, so the child doesn't survive test failure
to send SIGALRM to other tests later (there are also
baffling SIGALRM-related failures in test_socket).
- Cancel the alarm in the finally clause -- if the
test dies early, we again don't want SIGALRM showing
up to confuse a later test.
Alas, this still relies on timing luck wrt the spawned
script that sends the test signals, but it's hard to see
how waiting for seconds can so often be so unlucky.
test_threadedsignals: curiously, this test never fails
on Tru64, but doesn't normally signal SIGALRM. Anyway,
fixed an obvious (but probably inconsequential) logic
error.
2006-08-12 01:42:47 -03:00
|
|
|
# Restore handlers.
|
|
|
|
signal.alarm(0) # cancel alarm in case we died early
|
2004-06-11 15:09:28 -03:00
|
|
|
signal.signal(signal.SIGHUP, hup)
|
|
|
|
signal.signal(signal.SIGUSR1, usr1)
|
|
|
|
signal.signal(signal.SIGUSR2, usr2)
|
|
|
|
signal.signal(signal.SIGALRM, alrm)
|