Proper fix for the lazy workaround in 7e1774f7
authorDagfinn Ilmari Mannsåker <ilmari@ilmari.org>
Mon, 8 Feb 2016 16:31:22 +0000 (16:31 +0000)
committerPeter Rabbitson <ribasushi@cpan.org>
Thu, 11 Feb 2016 18:45:16 +0000 (19:45 +0100)
commitd52fc26dd05b56a41494a5ec86cddecfe3587b96
tree2ebf699496c81a011d8bae003357ff2c9cc37624
parent7e1774f762f0290fae3f9f9104a5d5dc52a1c017
Proper fix for the lazy workaround in 7e1774f7

Pure-perl subs return values as mortal copies on the stack, incrementing
the reference count until the next statement.  In the case of the last
statement in a sub, that is in the caller, after the other lexicals have
been GCed.

  if ( ... ) { ... };

counts as a single statement for this purpose, since it compiles to

  ( ... ) && do { ... };

The reason this doesn't bite when using XS is that Class::XSAcessor
returns the SV directly from the hash, rather than a mortal copy, so the
reference count never gets incremented.

Generalize the fix to a similar problem (8e9b9ce5) and pepper potentially
problematic codepaths with explicit NEXTSTATEs. Many of the changes do not
resolve anything as there is no "statement leakage" in most of this code,
but it is a good idea to have them there nevertheless: This way future
code-flow modifications will not accidentally reintroduce this problem.
lib/DBIx/Class/ResultSource.pm
lib/DBIx/Class/Schema.pm
lib/DBIx/Class/Storage/DBI.pm
lib/DBIx/Class/Storage/DBI/Cursor.pm
lib/DBIx/Class/Storage/TxnScopeGuard.pm
lib/DBIx/Class/_Util.pm
t/lib/DBICTest/Util/LeakTracer.pm