test_uuid leaks references

[encukou]

Two out of three test_uuid runs leak references. This is hidden by the all() heuristic in regrtest.

Output with #115720:

$ ./python -m test test_uuid -R3:20
...
beginning 23 repetitions. Showing number of leaks (. for zero, X for 10 or more)
123:45678901234567890123
X4. 6.16.16.16.16.16.16.

[vstinner]

I modified refleak.py:

diff --git a/Lib/test/libregrtest/refleak.py b/Lib/test/libregrtest/refleak.py
index 71a70af688..4921999ccc 100644
--- a/Lib/test/libregrtest/refleak.py
+++ b/Lib/test/libregrtest/refleak.py
@@ -145,7 +145,7 @@ def check_rc_deltas(deltas):
         #
         #   [5, 5, 6]
         #   [10, 1, 1]
-        return all(delta >= 1 for delta in deltas)
+        return any(delta >= 1 for delta in deltas)
 
     def check_fd_deltas(deltas):
         return any(deltas)

I'm not convinced that it's a leak:

$ ./python -m test test_uuid -R3:20 
Using random seed: 3336235121
0:00:00 load avg: 5.67 Run 1 test sequentially
0:00:00 load avg: 5.67 [1/1] test_uuid
beginning 23 repetitions
12345678901234567890123
.......................
test_uuid leaked [6, -6, 1, 6, -6, 1, 6, -6, 1, 6, -6, 1, 6, -6, 1, 6, -6, 1, 6, -6] references, sum=6
test_uuid leaked [3, -3, 0, 3, -3, 0, 3, -3, 0, 3, -3, 0, 3, -3, 0, 3, -3, 0, 3, -3] memory blocks, sum=0
test_uuid failed (reference leak)

It's just that some objects deletion are delayed to the next iteration: they are many "negative leaks" :-)

[vstinner]

Using my patch, I can reproduce the issue with these 3 patches:

./python -m test test_uuid -R3:10 -m test.test_uuid.TestUUIDWithoutExtModule.test_uuid1 -m test.test_uuid.TestUUIDWithExtModule.test_uuid1 -m test.test_uuid.TestUUIDWithExtModule.test_safe_uuid_enum