It's not one of my direct dependencies and I don't believe that it is a
transitive dependency either because it isn't installed on my test server.
On Thu, Sep 17, 2015 at 1:26 PM, Michael Schout <msch...@gkg.net> wrote:
> On 9/17/15 9:00 AM, John Dunlap wrote:
> > I'm not using the TryCatch module in my application. I use eval blocks
> > for all of my transaction management. For me to be suffering from the
> > same ailment, the bug would have to manifest itself in other ways.
>
> I don't think TryCatch *itself* is the problem. I was seeing
> segmentation faults from other sections of code that did not use
> TryCatch that the op.c change apparently also causes.
>
> There is some other underlying problem that is causing this. You can
> put other chunks of code inside the try { } block and the panic does not
> happen. For some reason $cgi->param() inside the try *does* trigger it,
> but it also needs to be called from a subroutine (e.g.: moving the try
> block inside the handler() sub does not cause the panic. This all sort
> of makes sense based on what the change to op.c does to the optree that
> causes the bug (skips over "return" ops that do nothing basically)
>
> In addition I had other segfaults that DO NOT issue the "panic" warning.
> But reversing the optimization to op.c in perl fixes that for me also.
>
> I haven't had time to really try to get into the modperl code enough to
> know what is going on, but the backtrace from panic is coming from
> copying scalars that have flags or something to that effect when leaving
> a subroutine. I'm pretty sure modperl messes with scalar flags and/or
> scalar magic due to previous experience with the mod_perl codebase a
> long time ago so that might explain why this ONLY happens under modperl
> and not under vanilla perl.
>
> Also, TryCatch is implemented using Devel::Declare, which is admittedly
> sneaky because it screws with the perl optree during compilation. The
> part that was changed in op.c that causes the problems this thread is
> about essentially "skip over" a couple of unnecessary ops as an
> optimization.
>
> So this is a bit long winded, but I kind of doubt TryCatch is the
> problem. TryCatch+CGI->param called from a soubroutine just happens to
> be one of the shortest, sure fire ways to trigger the panic that I have
> found when I needed to make a test case to demonstrate the bug.
>
> I suspect Devel::Declare was getting away with something that it
> shouldn't be able to do, or, something in modperl at this time.
>
> Is Devel::Declare a dependency anywhere in your codebase? E.g.: if you
> have Devel/Declare.pm in your perl library path, will you code still run
> if you remove Devel/Declare.pm? If so then that either means the
> problem is probably in modperl itself, or, you are seeing something
> completely different.
>
> Regards,
> Michael Schout
>
--
John Dunlap
*CTO | Lariat *
*Direct:*
*j...@lariat.co <j...@lariat.co>*
*Customer Service:*
877.268.6667
supp...@lariat.co
