Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve test_os._kill (failing on slow machines) #52652

Closed
briancurtin opened this issue Apr 15, 2010 · 6 comments
Closed

Improve test_os._kill (failing on slow machines) #52652

briancurtin opened this issue Apr 15, 2010 · 6 comments
Assignees
Labels
OS-windows stdlib Python modules in the Lib dir type-bug An unexpected behavior, bug, or error

Comments

@briancurtin
Copy link
Member

BPO 8405
Nosy @vstinner, @bitdancer, @briancurtin
Files
  • fix_test_os.diff: patch against trunk
  • issue8405.diff: trunk
  • Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

    Show more details

    GitHub fields:

    assignee = 'https://github.com/briancurtin'
    closed_at = <Date 2010-05-28.16:09:28.111>
    created_at = <Date 2010-04-15.02:42:01.217>
    labels = ['type-bug', 'library', 'OS-windows']
    title = 'Improve test_os._kill (failing on slow machines)'
    updated_at = <Date 2010-05-28.16:30:04.465>
    user = 'https://github.com/briancurtin'

    bugs.python.org fields:

    activity = <Date 2010-05-28.16:30:04.465>
    actor = 'vstinner'
    assignee = 'brian.curtin'
    closed = True
    closed_date = <Date 2010-05-28.16:09:28.111>
    closer = 'brian.curtin'
    components = ['Library (Lib)', 'Windows']
    creation = <Date 2010-04-15.02:42:01.217>
    creator = 'brian.curtin'
    dependencies = []
    files = ['16928', '17473']
    hgrepos = []
    issue_num = 8405
    keywords = ['patch']
    message_count = 6.0
    messages = ['103179', '103245', '103317', '106611', '106676', '106677']
    nosy_count = 3.0
    nosy_names = ['vstinner', 'r.david.murray', 'brian.curtin']
    pr_nums = []
    priority = 'normal'
    resolution = 'fixed'
    stage = 'resolved'
    status = 'closed'
    superseder = None
    type = 'behavior'
    url = 'https://bugs.python.org/issue8405'
    versions = ['Python 2.7', 'Python 3.2']

    @briancurtin
    Copy link
    Member Author

    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.

    @briancurtin briancurtin self-assigned this Apr 15, 2010
    @briancurtin briancurtin added stdlib Python modules in the Lib dir OS-windows type-bug An unexpected behavior, bug, or error labels Apr 15, 2010
    @bitdancer
    Copy link
    Member

    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.

    @vstinner
    Copy link
    Member

    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

    @briancurtin
    Copy link
    Member Author

    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.

    @briancurtin
    Copy link
    Member Author

    Committed to trunk in r81584 and py3k in r81585.

    @vstinner
    Copy link
    Member

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

    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Labels
    OS-windows stdlib Python modules in the Lib dir type-bug An unexpected behavior, bug, or error
    Projects
    None yet
    Development

    No branches or pull requests

    3 participants