test_kqueue failure on OS X

[mdickinson]

BPO	5025
Nosy	@mdickinson, @tiran
Files	issue5025.patch

^{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/mdickinson'
closed_at = <Date 2009-01-24.16:18:42.621>
created_at = <Date 2009-01-21.17:58:18.050>
labels = ['tests']
title = 'test_kqueue failure on OS X'
updated_at = <Date 2009-01-24.16:18:42.620>
user = 'https://github.com/mdickinson'

bugs.python.org fields:

activity = <Date 2009-01-24.16:18:42.620>
actor = 'mark.dickinson'
assignee = 'mark.dickinson'
closed = True
closed_date = <Date 2009-01-24.16:18:42.621>
closer = 'mark.dickinson'
components = ['Tests']
creation = <Date 2009-01-21.17:58:18.050>
creator = 'mark.dickinson'
dependencies = []
files = ['12828']
hgrepos = []
issue_num = 5025
keywords = ['patch']
message_count = 5.0
messages = ['80335', '80336', '80341', '80445', '80458']
nosy_count = 3.0
nosy_names = ['exarkun', 'mark.dickinson', 'christian.heimes']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue5025'
versions = ['Python 2.6']

[mdickinson]

I just got a one-off, non-reproducible test_kqueue failure, during a 'make
test' of the trunk, on OS X 10.5.6. Here's the output:

test_kqueue
test test_kqueue failed -- Traceback (most recent call last):
  File "/Users/dickinsm/python_source/trunk/Lib/test/test_kqueue.py", line 
136, in test_queue_event
    (server.fileno(), select.KQ_FILTER_READ, flags)])
AssertionError: [(5L, -2, 5L), (6L, -2, 5L), (6L, -1, 5L)] != [(5, -2, 5), 
(5, -1, 5), (6, -2, 5), (6, -1, 5)]

Looking at the test_queue.py file just before line 136, I see:

        events = kq.control(None, 4, 1)
        # We may need to call it several times
        for i in range(5):
            if len(events) == 4:
                break
            events = kq.control(None, 4, 1)

Would adding a time.sleep(1.0) to the for loop make this test more robust?

My first impression was that the '1' in 'kq.control(None, 4, 1)' already
did this; i.e., that it meant that the kq.control function would wait up
to 1 second for a response, but that doesn't seem to be true. I tried
replacing the 1 with 1000000 and the test still runs nearly
instantaneously, even in the case where the kq.control call doesn't get 4
events first time around.

Out of curiosity, *why* is there a need to call this several times? I
fully believe there *is* such a need; I just don't know what it is.
Something to do with waiting for the socket send calls to complete, I
assume?

[exarkun]

My first impression was that the '1' in 'kq.control(None, 4, 1)'
already did this; i.e., that it meant that the kq.control function
would wait up to 1 second for a response, but that doesn't seem to be true.

Since there are events in the result, the call succeeds immediately.
The timeout only defines an upper bound on how long control will block
before returning with *no* results. Since the loop doesn't handle any
of the events, there's always some ready right away after the first call.

Out of curiosity, *why* is there a need to call this several times?

It's out of the control of the test what the kernel does to deliver the
event notifications. Since the test is waiting for multiple events, the
loop helps it get them all (although clearly it's not totally reliable).

[mdickinson]

Here's a patch:

• add a time.sleep(1.0) in between calls to kq.control
• restructure for loop slightly: move initial kq.control call inside it
• bump number of trials from 5 to 10 (why not?!)
• produce more meaningful error message in the unlikely event
  that we never get the 4 events we're waiting for

[mdickinson]

I just saw this same test_kqueue failure pop up on the OS X 3.x buildbot,
so it's evidently not just a peculiarity of my machine.

Unless there are any objections, I'll go ahead and check this in: I think
it's a sufficiently trivial fix that it's not worth wasting Christian's
time with. :)

[mdickinson]

Fixed in the trunk in r68897. Will merge to 2.6, 3.0 and 3.1.