@@ -445,9 +445,28 @@ def __call__(self):
445445 # due to working set trimming, page table updates, etc. Allow a
446446 # small tolerance so OS-level noise doesn't cause false failures.
447447 # Real leaks produce MBs of growth (each iteration creates 20k
448- # greenlets), so 512 KB is well below the detection threshold for
449- # genuine issues.
450- tolerance = 512 * 1024 if WIN else 0
448+ # greenlets; the greenlet Python object alone, not counting the C++
449+ # state it points to, is 56 bytes so 20k greenlets alone is
450+ # slightly over a megabyte; the C++ UserGreenlet clocks in at 208
451+ # bytes, which adds another 4MB), so 512 KB is well below the detection
452+ # threshold for genuine issues.
453+ #
454+ # 2025-06-16: We have now observed the same problem on both
455+ # ubuntu-latest 3.14t (2948K "leak") and macos-latest 3.15t (192K
456+ # "leak"). This was after the merge of PR #511, but that change
457+ # should be unrelated. In particular, the ubuntu failure was after
458+ # 30 loops and the macos failure was after only 3 --- both much
459+ # smaller than UNTRACK_ATTEMPTS=100! We break out of the loop if we
460+ # see a USS at the end of the loop that's smaller than at the start
461+ # of the loop, and then we wait for pending cleanups and get the
462+ # USS again. So this means that we think we have success, break out
463+ # of the loop, and the pending cleanups cause our USS to grow -
464+ # perhaps by touching pages that had been paged out? An immediately
465+ # prior attempt of both platforms had been successful.
466+ #
467+ # At any rate, we need a larger tolerance than 512K, and we
468+ # need it on all platforms, not just Windows.
469+ tolerance = 3 * 1024 * 1024
451470 self .assertLessEqual (uss_after , uss_before + tolerance ,
452471 "after attempts %d" % (count ,))
453472
0 commit comments