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
Tied methods break when combined with eval() of failing compile-time code #6766
Comments
From jason@gossamer-threads.comThe following example demonstrates the problem quite well: perl -e ' package main; print "Calling FETCH explicitly ...\n"; print "\tdone.\nCalling FETCH implicitly ...\n"; print "\tdone.\n" The output from this is: Calling FETCH explicitly ... In more complex situations, this causes Perl to segfault (at once point Just for fun, I threw the implicit FETCH inside a subroutine (sub main) I figured out a rather nasty workaround, by wrapping the eval around eval q{my $ret = eval "BEGIN { some bad code }"; die "$@\n" if $@; $ret}; I'm curious why the extra eval makes this work - admittedly it was Perl Info
|
From @iabynOn Mon, Sep 15, 2003 at 09:18:13AM -0000, Jason Rhinelander wrote:
Perl is incorrectly popping too much context off the stack in the implicit Executing similar code (where I replaced the BEGIN {..} with BEGIN {die }, implicit call STACK 0: MAIN ((eval 2):1) die STACK 0: MAIN explicit call STACK 0: MAIN ((eval 1):1) die STACK 0: MAIN (Note that in the implicit case, there are two context stacks, due to tracing the code shows that die_where correctly pops the EVAL/EVAL/SUB, At this point I give up, since the mechanisms for longjmping in Perl for Dave. -- |
From s0710509@u.tsukuba.ac.jpThis is a bug report for perl from s0710509@unix01.u.tsukuba.ac.jp, eval "use $module" in Perl_call_sv() without G_EVAL could cause segmentation faults on some perls. With G_EVAL, it doesn't occur. gdb(1) suggests that segv occurs in setjmp(3), but I don't know its details. See the following code: # FETCH() is called via Perl_call_sv() Flags: This perlbug was built using Perl 5.10.0 - Mon Jun 29 11:42:33 JST 2009 Site configuration information for perl 5.10.1: Configured by s0710509 at Wed Aug 26 15:19:00 JST 2009. Summary of my perl5 (revision 5 version 10 subversion 1) configuration: Locally applied patches: @INC for perl 5.10.1: Environment for perl 5.10.1: |
From jarich@perltraining.com.auG'day, Thank you for spotting this bug, this is indeed an issue. We'll do what All the best, Jacinta |
The RT System itself - Status changed from 'new' to 'open' |
@iabyn - Status changed from 'open' to 'resolved' |
From @cpansproutThis was fixed by 27e9045. |
@cpansprout - Status changed from 'open' to 'resolved' |
I've been looking at commit 27e9045 (while investigating something else). It appears that the changes made in that commit are no longer needed to make the test cases pass. I don't know if there are cases that still need the (extra) JMPENV level that is created in |
On Sat, 27 Aug 2022, 15:37 Bram, ***@***.***> wrote:
I've been looking at commit 27e9045
<27e9045>
(while investigating something else).
It *appears* that the changes made in that commit are no longer needed to
make the test cases pass.
In commit d7e3f70
<d7e3f70>
(for issue #11804 <#11804>) changes
were made which causes PP(pp_entereval) to add it's own JMPENV level when
CATCH_GET is true.
I don't know if there are cases that still need the (extra) JMPENV level
that is created in S_try_yyparse (or where it would be desirable).
(The test suite still passes if I change the code to always call yyparse
and never S_try_yyparse
That is because currently try_yyparse is never called as CATCH_GET is never
true.
Yves
… |
Migrated from rt.perl.org#23810 (status was 'resolved')
Searchable as RT23810$
The text was updated successfully, but these errors were encountered: