homepage

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

AltStyle によって変換されたページ (->オリジナル) /