perl -e "1for$[=0" crash #7977
Comments
From fox@scene.plThis is a bug report for perl from fox@scene.pl, perl -e "1for$[=0" causes a null pointer dereference. Flags: Site configuration information for perl v5.8.0: Configured by ActiveState at Mon Mar 31 00:45:28 2003. Summary of my perl5 (revision 5 version 8 subversion 0) configuration: Locally applied patches: @INC for perl v5.8.0: Environment for perl v5.8.0: |
From @schwernOn Thu, Jun 16, 2005 at 03:54:18PM -0000, Piotr Fusik wrote:
Confirmed in 5.8.1RC3, 5.8.6 and bleadperl@24148 on OS X 10.3 -- |
|
The RT System itself - Status changed from 'new' to 'open' |
From @smpetersOn Thu, Jun 16, 2005 at 11:17:35AM -0700, Michael G Schwern wrote:
The attached patch prevents the coredump by die'ing instead. While trying to investigate what the valid syntax for "for" Steve Peters Inline Patch--- op.c.old Mon Jun 13 11:52:00 2005
+++ op.c Thu Jun 16 13:53:26 2005
@@ -3901,6 +3901,10 @@
I32 iterflags = 0;
I32 iterpflags = 0;
+ if (!expr) {
+ DIE(aTHX_ "\"for\" missing a conditional expression");
+ }
+
if (sv) {
if (sv->op_type == OP_RV2SV) { /* symbol table variable */
iterpflags = sv->op_private & OPpOUR_INTRO; /* for our $x () */ |
From @rgarciaOn 6/16/05, Steve Peters <steve@fisharerojo.org> wrote:
Surely you jest. for is used quite often to alias a variable to $_, However you correctly found the cause of the problem. $[ is a Note that other kinds of similar code segfaults too : $ perl -e 'if($[=0){print}' I'd rather solve all those cases once and for all. |
From @AbigailOn Thu, Jun 16, 2005 at 11:17:35AM -0700, Michael G Schwern wrote:
Quite old, actually: $ /opt/perl/5.005/bin/perl -e '1for$[=0' But: $ /opt/perl/5.004_04/bin/perl -e '1for$[=0' Abigail |
From @hvdsRafael Garcia-Suarez <rgarciasuarez@gmail.com> wrote: It sounds like the bug is in the optimiser: if it acts on C< $[ = 0 > Hugo |
From @smpetersOn Fri, Jun 17, 2005 at 12:00:07AM +0100, hv@crypt.org wrote:
I see this sort of behavior more when putting the code into a quoted steve@kirk:~/sandbox$ perl -le'eval "1 for An eval'ed block just SEGVs as the normal code does. At semi-random intervals Steve Peters |
From rick@bort.caOn Fri, Jun 17, 2005 at 12:00:07AM +0100, hv@crypt.org wrote:
This patch should do that. It also fixes this: % perl -wle '( by disallowing it. It now gives: That use of $[ is unsupported at -e line 1. -- Inline Patch |
From @AbigailOn Thu, Jun 16, 2005 at 10:24:24PM -0500, Steve Peters wrote:
Well, Abigail |
From rick@bort.caOn Fri, Jun 17, 2005 at 10:31:19PM -0400, Rick Delaney wrote:
Oops, those last two test cases aren't quite right since they could be -- Inline Patchdiff -ruN perl-current/.patch perl-current-dev/.patch
--- perl-current/.patch 2005-06-18 13:03:29.000000000 -0400
+++ perl-current-dev/.patch 2004-11-03 08:20:39.000000000 -0500
@@ -1 +1 @@
-24895
+23469
diff -ruN perl-current/op.c perl-current-dev/op.c
--- perl-current/op.c 2005-06-16 06:15:46.000000000 -0400
+++ perl-current-dev/op.c 2005-06-17 22:00:03.000000000 -0400
@@ -3274,14 +3274,15 @@
OP *curop;
PL_modcount = 0;
- PL_eval_start = right; /* Grandfathering $[ assignment here. Bletch.*/
+ /* Grandfathering $[ assignment here. Bletch.*/
+ /* Only simple assignments like C<< ($[) = 1 >> are allowed */
+ PL_eval_start = (left->op_type == OP_CONST) ? right : 0;
left = mod(left, OP_AASSIGN);
if (PL_eval_start)
PL_eval_start = 0;
- else {
- op_free(left);
- op_free(right);
- return Nullop;
+ else if (left->op_type == OP_CONST) {
+ /* Result of assignment is always 1 (or we'd be dead already) */
+ return newSVOP(OP_CONST, 0, newSViv(1));
}
/* optimise C<my @x = ()> to C<my @x>, and likewise for hashes */
if ((left->op_type == OP_PADAV || left->op_type == OP_PADHV)
@@ -3418,8 +3419,7 @@
if (PL_eval_start)
PL_eval_start = 0;
else {
- op_free(o);
- return Nullop;
+ o = newSVOP(OP_CONST, 0, newSViv(PL_compiling.cop_arybase));
}
}
return o;
diff -ruN perl-current/t/comp/parser.t perl-current-dev/t/comp/parser.t
--- perl-current/t/comp/parser.t 2004-06-24 12:47:01.000000000 -0400
+++ perl-current-dev/t/comp/parser.t 2005-06-18 17:44:05.324160600 -0400
@@ -9,7 +9,7 @@
}
require "./test.pl";
-plan( tests => 47 );
+plan( tests => 54 );
eval '%@x=0;';
like( $@, qr/^Can't modify hash dereference in repeat \(x\)/, '%@x=0' );
@@ -168,3 +168,25 @@
eval q{ sub _ __FILE__ {} };
like($@, qr/Illegal declaration of subroutine main::_/, "__FILE__ as prototype");
}
+
+# [perl #36313] perl -e "1for$[=0" crash
+{
+ my $x;
+ $x = 1 for $[ = 0;
+ pass('optimized assignment to $[ used to segfault in scalar context');
+ if (($[) = 0) { $x = 1 }
+ pass('optimized assignment to $[ used to segfault in list context');
+ $x = ($[=2.4);
+ is($x, 2, 'scalar assignment to $[ behaves like other variables');
+ $x = (($[) = 0);
+ is($x, 1, 'list assignment to $[ behaves like other variables');
+ $x = eval q{ ($[, $x) = (0) };
+ like($@, qr/That use of \$\[ is unsupported/,
+ 'cannot assign to $[ in a list');
+ eval q{ ($[) = (0, 1) };
+ like($@, qr/That use of \$\[ is unsupported/,
+ 'cannot assign list of >1 elements to $[');
+ eval q{ ($[) = () };
+ like($@, qr/That use of \$\[ is unsupported/,
+ 'cannot assign list of <1 elements to $[');
+} |
From fox@scene.pl+ Looks like the descriptions of contexts are swapped (i.e. "for" should be Piotr Fusik |
From rick@bort.caOn Sun, Jun 19, 2005 at 11:34:55AM -0000, Piotr Fusik wrote:
No, the first assignment is in scalar context and the second (with -- Inline Patch |
From fox@scene.pl
I thought "the assignment" is "the = operator". So: Consider this: |
From @rgsRick Delaney wrote:
Thanks, applied as #24901. |
|
@rgs - Status changed from 'open' to 'resolved' |
From @ysthOn Mon, Jun 20, 2005 at 10:44:30AM -0000, Piotr Fusik wrote:
No, you are correct. I believe Rick was speaking imprecisely, meaning |
From rick@bort.caOn Mon, Jun 20, 2005 at 03:03:20AM -0700, Yitzchak Scott-Thoennes wrote:
Right. And that's what the tests are meant to, er, test. So they pass('optimized scalar assignment to $[ used to segfault'); but I think I've done enough damage. Patches welcome. :-) -- |
Migrated from rt.perl.org#36313 (status was 'resolved')
Searchable as RT36313$
The text was updated successfully, but these errors were encountered: