Skip to content

Occasionally multiprocessing.test.*.test_threads can take 10 minutes #113205

Description

@gpshead

Bug report

Bug description:

See the logs in https://buildbot.python.org/all/#/builders/1138/builds/498

10 slowest tests:
- test.test_multiprocessing_spawn.test_threads: 10 min 14 sec
- test.test_multiprocessing_fork.test_threads: 10 min 13 sec
- test_imaplib: 1 min 31 sec
- test_signal: 1 min 18 sec
- test.test_multiprocessing_spawn.test_processes: 52.6 sec
- test.test_concurrent_futures.test_wait: 48.6 sec
- test_socket: 40.7 sec
- test.test_multiprocessing_forkserver.test_processes: 40.1 sec
- test_io: 37.4 sec
- test_codecs: 37.3 sec

Normally those two .test_threads sub-suites in test_multiprocessing do not make the top 10 slowest at all.

Something odd is going on and occasionally making them sit around for a very long time before apparently succeeding anyways. I've seen it multiple time in the rpi buildbot logs. I expect it'll show up on some other bots as well but I haven't gone hunting.

CPython versions tested on:

3.12

Operating systems tested on:

Linux

Linked PRs

Activity

  1. added
    type-bugAn unexpected behavior, bug, or error
    testsTests in the Lib/test dir
    on Dec 16, 2023
  2. added
    3.11only security fixes
    3.12only security fixes
    on Dec 19, 2023
  3. gpshead commented on Dec 19, 2023

    @gpshead
    MemberAuthor

    Notably I'm not seeing this on the main 3.x branch builds, only 3.12 and 3.11. https://buildbot.python.org/all/#/workers/25

  4. encukou commented on Jan 17, 2024

    @encukou
    Member

    It appears on Windows too, and there the refleak buildbot sometimes fails with a timeout.

    I will investigate.

  5. encukou commented on Jan 17, 2024

    @encukou
    Member

    WithThreadsTestPool.test_terminate takes LONG_TIMEOUT (5 minutes) in about 1.5% cases (on my machine).

    It happens when the first task starts executing before termination. Unlike processes, threads can't be safely forcefully stopped, so the expected behaviour of ThreadPool.terminate is to wait for in-progress tasks to finish.
    But the test is designed for process pools, and it uses very long tasks.

    On main, the test is now skipped for threads entirely. We can do better: for threads, use a shorter task, but still make sure the API works.

  6. added a commit that references this issue on Jan 17, 2024
  7. added a commit that references this issue on Jan 18, 2024
  8. added 2 commits that reference this issue on Jan 18, 2024
  9. gpshead commented on Jan 18, 2024

    @gpshead
    MemberAuthor

    The merged PR in main has a few buildbot failures. is this perhaps related: https://buildbot.python.org/all/#/builders/345/builds/6859/steps/5/logs/stdio

  10. encukou commented on Jan 18, 2024

    @encukou
    Member

    The PR changed one specific case, so it's unrelated.
    But I'll look at those failures anyway, with higher priority than backporting this fix.

  11. 5 remaining items

  12. serhiy-storchaka commented on Jan 18, 2024

    @serhiy-storchaka
    Member

    It is disturbing that it only happens in 1.5% cases. It means that in majority of cases terminate() is called when no tasks was even started. It is perhaps not for what this test was purposed (by running slow tasks which take "forever" to complete).

  13. added a commit that references this issue on Jan 18, 2024
  14. added a commit that references this issue on Jan 22, 2024
  15. added a commit that references this issue on Jan 24, 2024
  16. added 2 commits that reference this issue on Jan 24, 2024
  17. added 2 commits that reference this issue on Jan 24, 2024
  18. encukou commented on Jan 24, 2024

    @encukou
    Member

    We could also go all the way and let the worker signal its start using a event or queue, but sleep is good enough.

  19. added 2 commits that reference this issue on Feb 11, 2024
  20. added 2 commits that reference this issue on Sep 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

3.11only security fixes3.12only security fixestestsTests in the Lib/test dirtopic-multiprocessingtype-bugAn unexpected behavior, bug, or error

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions