develooper Front page | perl.perl5.porters | Postings from May 2010

Re: [perl #75436] Segfault with lexical $_ and reverse() since e1f795dc

Thread Previous | Thread Next
Vincent Pit
May 30, 2010 16:06
Re: [perl #75436] Segfault with lexical $_ and reverse() since e1f795dc
Message ID:

> On 29 May 2010 20:19, Ævar Arnfjörð Bjarmason <> wrote:
>> This segfaults in everything from 5.10 to blead:
>>    perl -e 'sub eek { my $_ = $_[0]; reverse } eek(1)'
> Thanks for tracing this down.
> Some background :
> reverse() without arguments is special, because it defaults to $_ only
> when called in scalar context. That means that, unlike all other
> builtins that default to $_, you can't know at compile time whether it
> will read $_ or not, and you can't put this info in the optree. So you
> have to figure it out later, at runtime.
> find_rundefsvoffset() locates a lexical $_ in the pad at runtime;
> however we don't know if it's a "my" or an "our", and in this case the
> segfault is produced in the part of the statement:
> PAD_COMPNAME_FLAGS_isOUR(padoff_du), which doesn't work, because
> apparently it's intended for compile-time, not run-time.
That was also my analysis.

I've attached two patches that fix the issue. Both fetch the name sv
associated with $_ from the current run-time pad instead of the comppad.
The former inlines all the new required code in pp_reverse, while the
second one introduces a new find_rundefsv() function that abstracts this
logic. Since I suspect that the UNDERBAR macro is also wrong (it's
deemed to be called at run-time), my preferred solution would be to
apply the second patch, change UNDERBAR to use find_rundefsv(), and
deprecate find_rundefsvoffset() as I don't think it's really useful in
the end.


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About