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

not ok - fs_event_watch_dir_recursive and hrtime (MacOS) #2117

Closed
frol opened this issue Dec 17, 2018 · 6 comments
Closed

not ok - fs_event_watch_dir_recursive and hrtime (MacOS) #2117

frol opened this issue Dec 17, 2018 · 6 comments
Labels

Comments

@frol
Copy link

frol commented Dec 17, 2018

not ok 58 - fs_event_watch_dir_recursive
# timeout
# Output from process `fs_event_watch_dir_recursive`: (no output)
...
not ok 120 - hrtime
# exit code 6
# Output from process `hrtime`:
# Assertion failed in test/test-hrtime.c on line 50: diff < (uint64_t) 80 * NANOSEC / MILLISEC

https://travis-ci.org/conda-forge/libuv-feedstock/jobs/468732638

  • Version: 1.24.1
  • Platform: TravisCI / Mac OS X 10.13.3 (Build Version: 17D102)

1.24.1 on Linux/MacOS and 1.24.0 on MacOS releases work just fine.

@bnoordhuis
Copy link
Member

Some of the tests are timing-sensitive by nature, so some failures are expected if the machine is under high load. Is there a possibility for you to re-run the test suite a few times to see if they're persistent failures?

@frol
Copy link
Author

frol commented Dec 17, 2018

I have re-run them 3 times (twice yesterday and once today just before I posted the issue) and the results are the same. This CI is part of Conda Forge package manager and libuv test suite has been successfully passing all its tests since 1.6.1 release.

@bnoordhuis
Copy link
Member

I've been going through the changes in the last few releases but there are no clear candidates that could be responsible. Is there a way for you to bisect?

@frol
Copy link
Author

frol commented Dec 24, 2018

@bnoordhuis I will try to do that once I have some free time.

@frol
Copy link
Author

frol commented Feb 12, 2019

@bnoordhuis I haven't had a chance to bisect the issue, so I only state the obvious facts here:

bnoordhuis added a commit to bnoordhuis/libuv that referenced this issue Feb 12, 2019
Expecting `uv_sleep(45)` to wake up within 80 ms is not a reasonable
assumption: the operating system may not reschedule the process within
that time frame when the system is overloaded.

The test fails intermittently on our own CI and packagers have reported
similar failures.

Fixes: libuv#2117
@bnoordhuis
Copy link
Member

Looking at the test, I think it's simply making a bad assumption. I've opened #2186 to fix that.

bnoordhuis added a commit to bnoordhuis/libuv that referenced this issue Feb 21, 2019
Expecting `uv_sleep(45)` to wake up within 80 ms is not a reasonable
assumption: the operating system may not reschedule the process within
that time frame when the system is overloaded.

The test fails intermittently on our own CI and packagers have reported
similar failures.

Fixes: libuv#2117
PR-URL: libuv#2186
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
njlr pushed a commit to buckaroo-pm/libuv that referenced this issue Apr 5, 2019
Expecting `uv_sleep(45)` to wake up within 80 ms is not a reasonable
assumption: the operating system may not reschedule the process within
that time frame when the system is overloaded.

The test fails intermittently on our own CI and packagers have reported
similar failures.

Fixes: libuv#2117
PR-URL: libuv#2186
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants