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
