-
-
Notifications
You must be signed in to change notification settings - Fork 31.9k
regrtest: change -R/--huntrleaks rule to decide if a test leaks references #74959
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
Comments
Currently, regrtest considers that a test file leaks if at least one run increased or decreased the global reference counter. The problem is that in practice, Python is full of singletons, caches, and other jokes of the garbage collector, etc. To reduce false alarms and focus more on real bugs, I suggest to change the reference difference checker from: def check_rc_deltas(deltas):
return any(deltas) to: def check_rc_deltas(deltas):
return all(delta>=1 for delta in deltas) It would allow to ignore false positives like:
|
I had to write this change to be able to bisect bpo-30775 reference leak. Without this change, my bisection tool picked the wrong tests and failed to find the tests which leaked. For example, it took a subtest of tests which was considered as leaking because the reference differences was [3, 0, 0]. This pattern more looks like a late initialization than a real leak. In the case of the bpo-30775, a leak was closer to [222, 222, 225]: much more references than just 3 :-) Many leaks for all runs :-) |
Real-world examples of false positives from the x86 Gentoo Refleaks 2.7 buildbot: test_nntplib leaked [0, 85, 0] references, sum=85 |
It seems like the change works well since I didn't see any more false alarms on the Refleaks buildbots. I close the issue. The change has been applied to 2.7, 3.5, 3.6 and master branches. |
This change suddenly made detection of reference leaks a lot less effective. Now if you have a single 0 in the deltas list, it will consider there is no reference leak, even though all other values might be > 0. See https://bugs.python.org/issue31317#msg301064 for an example. Victor, it would be nice if you could find a less brutal heuristic. |
Antoine Pitrou: "Victor, it would be nice if you could find a less brutal heuristic." My current goal is to get green buildbots. If a buildbot is always red, it's hard to notify easily regressions. Since I rejected "false alarms" from refleak, the refleak buildbot already helped to identify a reference leak regression. I am talking about the Windows Refleak buildbot: http://buildbot.python.org/all/builders/AMD64%20Windows8.1%20Refleaks%203.x I'm now working on the x86 Gentoo Refleaks 3.x which raised strange issues like bpo-31217. I am already making regrtest stricter, but slowly, without breaking buildbots. It's a slow process. That's why I'm to "fix" dangling threads for example. By the way, I'm not done with dangling threads in master yet. I'm happy if anyone is interested to help me to work on buildbots, which means in practice fixing a new different bug everyday :-) Slowly, the remaining bugs are the most complex ones. |
Except that now it may hide actual regressions... False negatives are not better than false positives. |
Please put this issue in its context. 6 months ago, there was no more Refleak buildbot and everything was broken. If you want to make regrtest -R stricer, go ahead. But if a buildbot breaks, you will have to fix it. I would prefer to first fix the Gentoo Refleak buildbot, since most previous builds failed. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: