Re: panic: attempt to copy freed scalar caused by calling cgi->param with TryCatch since perl 5.19.7

John Dunlap <[email protected]>
Newsgroups gmane.comp.apache.mod-perl
Message-ID <CAC5eUSsO6+MdKqaCpA5yn++pSgtWSAqtV63uyhR-ze0XQWvK=w@mail.gmail.com>
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 <[email protected]> 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:*
*[email protected] <[email protected]>*

*Customer Service:*
877.268.6667
[email protected]
100x60.png (image/png, 2.1 KB) - not displayed
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.