On Mon, Jun 28, 2010 at 11:15 AM, Alex Hunsaker <bada...@gmail.com> wrote:
> Hi!
>
> perl: 5.10.1, 5.12.1 (i686-linux, x86_64-linux)
> mod_perl: 2.0.4
>
> Basically if you have end blocks that modify/add END blocks things
> might go crazy.
This sounds like it is similar to something Tim B. brought up a month
or so ago dealing with the new NYTProf release, but I wasn't able to
find the thread. Is this issue related?
> A simple test case for this is:
> package test:
> END { eval "END { }" for 1..10 }
>
> gives:
> Not a CODE reference.
> END failed--call queue aborted.
>
> if I add another END {}:
> package test:
> END { eval "END { }" for 1..10 }
> END { }
>
> I get:
> Undefined subroutine &main:: called.
> END failed--call queue aborted.
>
> This was found as I was getting strange segfaults when trying to use
> NYTProf. Nicholas Clark was able to pinpoint the problem.
>
> See:
> http://groups.google.com/group/develnytprof-dev/msg/4ff26e6b3d95861f
> thread:
> http://groups.google.com/group/develnytprof-dev/browse_thread/thread/20d2ea800e8936f
>
> Ive included some relevant bits here (again from Nicholas):
>
>> Of course, I looked at the core perl source to see how END blocks were run,
>> and the behaviour was safe with perl. perl unshifts each CV from the list
>> before it calls it. I should have remembered that inevitably mod_perl is
>> "special".
>>
>> On reflection, I think that this *is* a bug in mod_perl, as they're going
>> to get tripped up in similar fashion if any code run as part of an END block
>> contains a string eval containing an END block.
That doesn't seem like a widespread use case, but I can see how it
could occur unexpectedly and generate a fair amount of pain. But from
the times that I have used string eval's, it was always accompanied by
some pain.
> Now the simple fix would be to just make modperl shift things off as
> well (see attached patch to make it use Perl_call_list). Course if
> they use ModPerl::Global::special_list_(call|clear) like
> t/modperl/endav.t things break. As when we go to run END blocks or
> call special_list_call() they will have been shifted off. This might
> be acceptable behavior for END blocks, but I can see not wanting to
> break other things that use modperl_perl_call_use. Maybe, maybe not.
> Thoughts?
ModPerl::RegistryCooker appears to use the special_list calls.
http://perl.apache.org/docs/2.0/api/ModPerl/Global.html
So the fix could introduce some breakage into deployments which use MP::RC
> Another option would be to copy/local() the array in
> modpler_perl_call_list. Of course that still wont get it "right"
> because we wont run any newly defined subs... But at least we wont
> segfault/crap out.
>
> Thoughts?
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.
