Skip to content
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

'No such caller depth' with pure perl mod_perl6 #86

Closed
p6rt opened this issue May 19, 2008 · 4 comments
Closed

'No such caller depth' with pure perl mod_perl6 #86

p6rt opened this issue May 19, 2008 · 4 comments
Labels
Rakudo Tickets to be moved to rakudo/rakudo/issues

Comments

@p6rt
Copy link

p6rt commented May 19, 2008

Migrated from rt.perl.org#54444 (status was 'resolved')

Searchable as RT54444$

@p6rt
Copy link
Author

p6rt commented May 19, 2008

From @jeffhorwitz

while converting mod_perl6 from PIR to pure perl6, i encountered the
following error when running a handler​:

  No such caller depth
  current instr.​: 'parrot;ModParrot;HLL;perl6;handler' pc 62 (EVAL_13​:46)

i tracked down the error to this block in perl6's actions.pm​:

  unless $?BLOCK.symbol('$/') {
  $init.push( PAST​::Var.new( :name('$/'), :isdecl(1) ) );
  $?BLOCK.symbol( '$/', :scope('lexical') );
  $init.push(
  PAST​::Op.new(
  :inline(
  " %r = getinterp\n"
  ~ " %r = %r['lexpad';1]\n"
  ~ " if null %r goto no_match_to_copy\n"
  ~ " %r = %r['$/']\n"
  ~ " store_lex '$/', %r\n"
  ~ " no_match_to_copy​:\n"
  )
  )
  );
  }

this code assumes there is a previous call frame which might contain a
lexpad, which is always true when called from PIR or the PCT command line.
however, in a pure perl mod_perl6, a perl6 sub is called directly from C,
and therefore lives in the top level call frame. any reference to the
nonexistent previous frame using the interpreter object bombs out.

you can reproduce this problem in pure PIR with this​:

  .sub main :main
  $P0 = getinterp
  $P1 = $P0['lexpad';1]
  .end

if we want perl6 subs to be directly invokable from an embedded
environemnt, we either need to teach perl6 to be smarter about this or
change how parrot handles this kind of exception.

-jeff

@p6rt
Copy link
Author

p6rt commented May 19, 2008

From @jeffhorwitz

On Mon, 19 May 2008, Parrot via RT wrote​:

while converting mod_perl6 from PIR to pure perl6, i encountered the
following error when running a handler​:

No such caller depth
current instr.​: 'parrot;ModParrot;HLL;perl6;handler' pc 62 (EVAL_13​:46)

i tracked down the error to this block in perl6's actions.pm​:

    unless $?BLOCK\.symbol\('$/'\) \{
        $init\.push\( PAST​::Var\.new\( :name\('$/'\), :isdecl\(1\) \) \);
        $?BLOCK\.symbol\( '$/', :scope\('lexical'\) \);
        $init\.push\(
            PAST​::Op\.new\(
                :inline\(
                      "    %r = getinterp\\n"
                    ~ "    %r = %r\['lexpad';1\]\\n"
                    ~ "    if null %r goto no\_match\_to\_copy\\n"
                    ~ "    %r = %r\['$/'\]\\n"
                    ~ "    store\_lex '$/', %r\\n"
                    ~ "  no\_match\_to\_copy​:\\n"
                \)
            \)
        \);
    \}

this code assumes there is a previous call frame which might contain a
lexpad, which is always true when called from PIR or the PCT command line.
however, in a pure perl mod_perl6, a perl6 sub is called directly from C,
and therefore lives in the top level call frame. any reference to the
nonexistent previous frame using the interpreter object bombs out.

you can reproduce this problem in pure PIR with this​:

\.sub main :main
    $P0 = getinterp
    $P1 = $P0\['lexpad';1\]
\.end

if we want perl6 subs to be directly invokable from an embedded
environemnt, we either need to teach perl6 to be smarter about this or
change how parrot handles this kind of exception.

-jeff

After further investigation, it looks like the parrotinterpreter PMC is
validating caller depth before looking up the keyed item. So for
$P0['lexpad';1] it verifies there's a call frame 1 level up before doing
anything else. A backtrace reveals that the exception occurs at
parrotinterpreter.pmc​:426​:

  if (!ctx->current_sub)
  real_exception(interp, NULL, E_ValueError,
  "No such caller depth");

So it *does* find a valid context one level up, but no current_sub since
we're calling from C. Is it necessary for this to be fatal? Should we
return NULL here instead of bombing out?

@p6rt
Copy link
Author

p6rt commented May 20, 2008

From @pmichaud

Fixed by jhorwitz in r27668 by placing a handler around the exception.
Closing ticket.

Pm

@p6rt
Copy link
Author

p6rt commented May 20, 2008

@pmichaud - Status changed from 'new' to 'resolved'

@p6rt p6rt closed this as completed May 20, 2008
@p6rt p6rt added the Rakudo Tickets to be moved to rakudo/rakudo/issues label Jan 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Rakudo Tickets to be moved to rakudo/rakudo/issues
Projects
None yet
Development

No branches or pull requests

1 participant