Re: [PATCH] END blocks may segfault

[Tim Bunce <Ti...@pobox.com>]

On Wed, Jun 30, 2010 at 09:24:42AM -0600, Alex Hunsaker wrote:
> On Wed, Jun 30, 2010 at 02:49, Tim Bunce <Ti...@pobox.com> wrote:
> > On Tue, Jun 29, 2010 at 09:50:00PM -0700, Fred Moyer wrote:
> >> I think getting rid of the segfault is a good thing.  But if the main
> >> problem is issues with NYTProf, then it seems like this change won't
> >> solve the core problem of autogenerated null end blocks faulting.  I'm
> >> don't fully understand the scope of these issues yet, so my answers
> >> (and questions) may not be completely helpful.
> 
> Well, the point of the test case is it does not use NYTProf.  Sure It
> was found while playing with NYTProf. :)
> 
> > I suggest the code shift items off the main array, like perl does,
> > but also push those items onto a new temp array.
> > When there are no more items in the main array it would copy
> > the items back again (av_make() is handy for that).
> 
> Wouldn't the list keep getting longer each time?  For example take
> your test case:
> END { eval "END { }" for 1..10 }
> 
> The first time we run them we should shift of 11 items. The next time
> 21, etc.  Am I missing something? Perhaps some cool trick?  Thats why
> I was thinking local() or equiv would make the most sense.

I presume mod_perl doesn't shift the array because it wants the array to
persist to be used again later. If not then it should shift.

Otherwise running 11 the first and 21 the second is the right behavior
for this (very unusual) test case.

Tim.

p.s. I'm not familar enough with mod_perl not know the all issues
surrounding how it uses PL_endav. So if this thread continues I'd be
grateful if someone could give some background/context. Thanks.

Re: [PATCH] END blocks may segfault

[Alex Hunsaker <ba...@gmail.com>]

>>> On Wed, Jun 30, 2010 at 02:49, Tim Bunce <Ti...@pobox.com> wrote:
>>> > I suggest the code shift items off the main array, like perl does,
>>> > but also push those items onto a new temp array.

Find attached a patch that does the above (perhaps naively), passes a
make test and fixes the reported problems for me.

Re: [PATCH] END blocks may segfault

[Alex Hunsaker <ba...@gmail.com>]

On Wed, Jun 30, 2010 at 16:37, Tim Bunce <Ti...@pobox.com> wrote:
> On Wed, Jun 30, 2010 at 09:24:42AM -0600, Alex Hunsaker wrote:
>> On Wed, Jun 30, 2010 at 02:49, Tim Bunce <Ti...@pobox.com> wrote:
>> > I suggest the code shift items off the main array, like perl does,
>> > but also push those items onto a new temp array.

> I presume mod_perl doesn't shift the array because it wants the array to
> persist to be used again later.

Yeah... Basically when running under ModPerl::Registry it tries to
treat your script exactly like it is running under cgi.  So when the
script finish it runs end blocks.  When the next request comes in you
still want those end blocks to run.

>From the ModPerl::Registry documentation:
| END blocks encountered during compilation of a script, are called
|  after the script has completed its run, including subsequent
| invocations when the script is cached in memory. This is
| assuming that the script itself doesn't define a package on its
| own. If the script defines its own package, the END blocks in the
| scope of that package will be executed at the end of the interpretor's life.

> Otherwise running 11 the first and 21 the second is the right behavior
> for this (very unusual) test case.

Yeah... I think you are right, I was completely over thinking things I think.