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.

Sign up for GitHub

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

Jump to bottom

Fix two tests that fail on a heavily-loaded machine #38825

Merged
merged 2 commits into from
Oct 26, 2024
Merged

Fix two tests that fail on a heavily-loaded machine #38825

merged 2 commits into from
Oct 26, 2024

Commits on Oct 19, 2024

  1. src/sage/parallel/decorate.py: disable a stress-dependent test 

    One test in this file sets the timeout to 100ms and expects an easy
example to complete within that amount of time. It can still fail,
though, if the machine is under load:

  File "src/sage/parallel/decorate.py", line 519, in
  sage.parallel.decorate.fork
    Failed example:
      g(5, m=5)
    Expected:
      8
  Got:
      Killing subprocess 62130 with input ((5,), {'m': 5}) which
      took too long
      8

This example isn't really the purpose of the doctest -- its intent is
to show that there are hard examples that will NOT complete in
100ms. (That is much easier to do.) All things considered, we are
better off just dropping this one flaky example.
    @orlitzky
    orlitzky committed Oct 19, 2024
    Configuration menu
    Copy the full SHA
    b60d912 View commit details
    Browse the repository at this point in the history

  2. src/sage/parallel/map_reduce.py: reduce test dependency on CPU speed 

    The test we have for start_workers() is doing a bit more than
that. It's starting two threads that each print something, sleep for a
bit, and then print something else. To check the expected output, we
are basically guessing how long it will take these threads to run, and
on a very heavily-loaded machine, we can guess wrong:

  File "src/sage/parallel/map_reduce.py", line 1149, in
  sage.parallel.map_reduce.RESetMapReduce.start_workers
  Failed example:
      sleep(float(1.5))
  Expected:
      Finished: ...
      Finished: ...
  Got:
      Finished: 2

(We were expecting both threads to finish within 1.5s, but only one
did.)

To make this a bit more robust, we eliminate the sleep() and
subsequent print inside of the threads. As a result, we need only make
one guess: how long it will take the threads to start. And for that we
now go overkill and wait 5s.
    @orlitzky
    orlitzky committed Oct 19, 2024
    Configuration menu
    Copy the full SHA
    a181883 View commit details
    Browse the repository at this point in the history