New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Segmentation fault with sub x { shift; @a = @b; eval { use } } #7082
Comments
From ion@alku.ion.yi.orgThis is a bug report for perl from ion+perlbug@ion.yi.org, $ perl -e 'sub x { shift; @a = @b; eval { use } }' To reproduce the segfault the following needs to be done in a sub: gdb backtrace: Flags: Site configuration information for perl v5.8.3: Configured by ion at Mon Jan 19 12:00:54 EET 2004. Summary of my perl5 (revision 5.0 version 8 subversion 3) configuration: Locally applied patches: @INC for perl v5.8.3: Environment for perl v5.8.3: |
From @iabynOn Mon, Feb 02, 2004 at 03:10:46AM -0000, ion@alku.ion.yi.org (via RT) wrote:
Thanks for the report. P5Pers: it can be reduced to: ./perl -e 'sub f { @a=@b=@c; {use} }' What is happening is that when 'use' is seen, the parser starts a new use : USE startsub This creates a new pad and updates PL_comppad, PL_curpad (with the old Clearly the correct fix is for the savestack to be properly popped during The index returned by start_subparse() somehow needs to be saved and Dave. -- |
The RT System itself - Status changed from 'new' to 'open' |
From @rgsQuoting Dave Mitchell <davem@fdisolutions.com>:
You can't define "properly" properly when there is a syntax error in
|
From @nwc10On Tue, Feb 03, 2004 at 05:08:52PM +0100, Rafael Garcia-Suarez wrote:
Does this mean that the bug is essentially unfixable without completely Nicholas Clark |
From @iabynOn Wed, Feb 04, 2004 at 10:34:10PM +0000, Nicholas Clark wrote:
No. As RGS reminded me, the 'sub;' bug (#18166) was fixable, so I presume -- |
From @iabynOn Wed, Feb 04, 2004 at 10:54:03PM +0000, Dave Mitchell wrote:
I've now had time to look at this. #18166 wasn't the bug I thought it was; I'll apply this after I've attempted to sort out run_byacc. Dave. -- Inline Patch--- ../22243/perly.y Wed Jan 28 22:05:50 2004
+++ perly.y Sat Feb 7 16:19:54 2004
@@ -83,7 +83,7 @@
%token COLONATTR
%type <ival> prog decl format startsub startanonsub startformsub
-%type <ival> progstart remember mremember '&'
+%type <ival> progstart remember mremember '&' savescope
%type <opval> block mblock lineseq line loop cond else
%type <opval> expr term subscripted scalar ary hsh arylen star amper sideff
%type <opval> argexpr nexpr texpr iexpr mexpr mnexpr mtexpr miexpr
@@ -162,16 +162,20 @@
{ $$ = block_start(FALSE); }
;
+savescope: /* NULL */ /* remember stack pos in case of error */
+ { $$ = PL_savestack_ix; }
+
/* A collection of "lines" in the program */
lineseq : /* NULL */
{ $$ = Nullop; }
| lineseq decl
{ $$ = $1; }
- | lineseq line
- { $$ = append_list(OP_LINESEQ,
- (LISTOP*)$1, (LISTOP*)$2);
+ | lineseq savescope line
+ { LEAVE_SCOPE($2);
+ $$ = append_list(OP_LINESEQ,
+ (LISTOP*)$1, (LISTOP*)$3);
PL_pad_reset_pending = TRUE;
- if ($1 && $2) PL_hints |= HINT_BLOCK_SCOPE; }
+ if ($1 && $3) PL_hints |= HINT_BLOCK_SCOPE; }
;
/* A "line" in the program */ |
From @iabynOn Sat, Feb 07, 2004 at 05:00:19PM +0000, Dave Mitchell wrote:
Having now "sorted out" run_byacc, I've applied this patch. I also However, the new bison parser actually seems to be better at error Dave.
-- |
From @iabynfixed in bleed by change #22306 |
@iabyn - Status changed from 'open' to 'resolved' |
Migrated from rt.perl.org#25824 (status was 'resolved')
Searchable as RT25824$
The text was updated successfully, but these errors were encountered: