[DBIx-Class-Devel] [dbix-class] Don't rollback when TxnScopeGuard dtor is run twice (#63)

Peter Rabbitson notifications at github.com
Sun Oct 26 10:20:17 GMT 2014


Thinking about this more - I now understand what is happening and it is **truly terrible** - Devel::StackTrace is very seriously broken, by *potentially* causing all destructors caught in a frame to run an unlimited number of times (until perl itself nukes the loop from orbit).

The fix for this lies within Devel::StackTrace - it **must** be adjusted to detect it is constructing a stacktrace from within DESTROY and **not** create any new refs to the refaddr of the argument to any higher DESTROY frames. Consider the following small (hence contrived) example:
```
perl -MDevel::StackTrace -e '
  sub DESTROY { warn "calling destructor and doing foo"; main::foo() };
  {
    my $trace;
    sub foo {
      $trace = Devel::StackTrace->new
    };

    { my $obj_to_be_destroyed = bless {} }

    print $trace->as_string
  }

  print "the end\n"
'
```

On why I qualify it as terrible - you already ran into an issue with a destructors written in a way that relies on it being a *highlander*. In this case the effect is a corrupted txn-state on a `$dbh`. There are many other cases where having a destructor execute twice will have worse consequences.

I am filing a Devel::StackTrace bug on RT with the above for @autarch

Thanks a ton to @nwellnhof for the initial investigative work that led to this diagnosis.

---
Reply to this email directly or view it on GitHub:
https://github.com/dbsrgits/dbix-class/pull/63#issuecomment-60512767
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scsys.co.uk/pipermail/dbix-class-devel/attachments/20141026/95164866/attachment.htm>


More information about the DBIx-Class-Devel mailing list