Fix intermittent failures in the LeakTracer on 5.18+, remove all workarounds
authorPeter Rabbitson <ribasushi@cpan.org>
Thu, 22 Jan 2015 22:27:22 +0000 (23:27 +0100)
committerPeter Rabbitson <ribasushi@cpan.org>
Fri, 13 Mar 2015 08:45:52 +0000 (09:45 +0100)
commit627d2b3dfa40adfc40a78ab270faefbc25ccb285
tree8aecb07a2c7af4b02d13c19de31671fa668e5d56
parent2bc8e9816f4e6985778d6f2ea27c936f80d0e48c
Fix intermittent failures in the LeakTracer on 5.18+, remove all workarounds

ARGH! In the end the issue turned out to be stupid-simple: when PadWalker is
called it always returns us a hashref. This hashref is traversed, with its
own address recorded as seen. Once processed, the hashref itself is GCed,
leaving a stale entry in $seen_refs.

Up until 5.18 this was not a problem, likely due to no address reuse. However
after 5.18 PadWalker is very happy to return different hashrefs under the same
address over and over again. The $seen_refs entry leads to a skip, and the
actual contents of the pad are never examined - we've seen this hash already.

ARGH!

The decisive change is the single line around PadWalker - everything else is
cleanup of workarounds for this problem.

(cherry pick of 1a77219a)
Changes
t/52leaks.t
t/lib/DBICTest/Util/LeakTracer.pm