This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Improve test_os._kill (failing on slow machines)
Type: behavior Stage: resolved
Components: Library (Lib), Windows Versions: Python 3.2, Python 2.7
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: brian.curtin Nosy List: brian.curtin, r.david.murray, vstinner
Priority: normal Keywords: patch

Created on 2010-04-15 02:42 by brian.curtin, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
fix_test_os.diff brian.curtin, 2010-04-15 02:41 patch against trunk
issue8405.diff brian.curtin, 2010-05-27 14:58 trunk
Messages (6)
msg103179 - (view) Author: Brian Curtin (brian.curtin) * (Python committer) Date: 2010-04-15 02:41
test_os._kill is used by test_kill_sigterm and test_kill_int and is failing on a slow Windows buildbot due to timing issues between the process starting and the signal being sent. I've checked in a few small time.sleep hacks in the meantime to see if that would help the bot, but I'd like to get a solid fix in there.

The attached patch adds a loop to the test function to see that even if the subprocess doesn't respond right away, it will have a few chances to respond and run the test. If the expected message isn't piped from the subprocess after 5 retries, the test fails.
msg103245 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2010-04-15 18:44
I like this version of the patch better.  Is there any reason not to drop the initial sleep(0.5) and loop 10 times instead?  Any place we can cut down the sleeps so the test suite runs faster on fast machines is good.

As someone else said, it *ought* to be possible to do this without ctypes.  I'll see if I can find some time to play a few subprocess games on my windows KVM instance.
msg103317 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2010-04-16 12:44
With the patch, the test have 1.0 second to succeed. I would prefer 5.0 or 10.0 seconds: it should not waste the 10 seconds because it should succeed if a new milliseconds. But if the machine is "slow" (which is the topic of the issue), you can give some more seconds to the test. So max=100, sleep=0.1
msg106611 - (view) Author: Brian Curtin (brian.curtin) * (Python committer) Date: 2010-05-27 14:58
I just noticed the other day that a buildbot failed because of this issue. Attached is a patch which removes the unconditional 0.5 sleep, and increases the loop to run 100 times. It should cover the worst case of a super slow buildbot, but is still typically complete in tenths of a second in the common case.
msg106676 - (view) Author: Brian Curtin (brian.curtin) * (Python committer) Date: 2010-05-28 16:09
Committed to trunk in r81584 and py3k in r81585.
msg106677 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2010-05-28 16:30
> Committed to trunk in r81584 and py3k in r81585

"sparc solaris10 gcc trunk" buildbot slave doesn't compile anymore. I'm not sure that it's related, so I prefer to not reopen the issue :-)

http://www.python.org/dev/buildbot/trunk/builders/sparc%20solaris10%20gcc%20trunk/builds/891

-----------
...
building '_struct' extension
gcc -fPIC -fno-strict-aliasing -g -O2 -g -O0 -Wall -Wstrict-prototypes -I. -IInclude -I./Include -I/usr/local/include -I/home2/buildbot/slave/trunk.loewis-sun/build/Include -I/home2/buildbot/slave/trunk.loewis-sun/build -c /home2/buildbot/slave/trunk.loewis-sun/build/Modules/_struct.c -o build/temp.solaris-2.10-sun4u-2.7-pydebug/home2/buildbot/slave/trunk.loewis-sun/build/Modules/_struct.o
gcc -shared build/temp.solaris-2.10-sun4u-2.7-pydebug/home2/buildbot/slave/trunk.loewis-sun/build/Modules/_struct.o -L/usr/local/lib -o build/lib.solaris-2.10-sun4u-2.7-pydebug/_struct.so
Assertion failed: min >= 0, file Python/getargs.c, line 1826
*** Error code 134
The following command caused the error:
case $MAKEFLAGS in \
*s*)  CC='gcc' LDSHARED='gcc -shared' LDFLAGS='' OPT='-g -O0 -Wall -Wstrict-prototypes' ./python -E ./setup.py -q build;; \
*)  CC='gcc' LDSHARED='gcc -shared' LDFLAGS='' OPT='-g -O0 -Wall -Wstrict-prototypes' ./python -E ./setup.py build;; \
esac
make: Fatal error: Command failed for target `sharedmods'
program finished with exit code 1
-----------
History
Date User Action Args
2022-04-11 14:56:59adminsetgithub: 52652
2010-05-28 16:30:04vstinnersetmessages: + msg106677
2010-05-28 16:09:28brian.curtinsetstatus: open -> closed
resolution: fixed
messages: + msg106676

stage: patch review -> resolved
2010-05-27 14:58:45brian.curtinsetfiles: + issue8405.diff

messages: + msg106611
2010-04-16 12:44:20vstinnersetnosy: + vstinner
messages: + msg103317
2010-04-15 18:44:09r.david.murraysetnosy: + r.david.murray
messages: + msg103245
2010-04-15 02:42:01brian.curtincreate