Closed lumimies closed 3 years ago
This seems to be a bug in the Grammar
implementation itself. It also happens without (not quite right, see below).Tracer
or Debugger
- you just don't see it (but rather go and kill your program after a while).
However, this seems to be a very valid thing for a Debugger to handle!
Now, assuming we've sped it up already (#10) and gotten rid of (again, not quite right).find_method
and hopefully don't override publish_method_cache
anymore - this seems to be a very valid reason for putting in our own find_method
again - and only for that!
What I wrote above is not entirely right.
No such method 'foo'
exception thrown.Routine.wrap
).find_method
but do override export_method_cache
so that find_method
in Metamodel::GrammarHOW
or up gets called, then it also does what it should, ie throws.find_method
and just say return callsame
in there, somehow our caller gets confused and thinks it should search for a method "Mu" (yes, the name as a string), which again is not found and so forth. This eventually yieldsmaximum recursion depth exceeded
current instr.: 'print_exception' pc 141508 (src\gen\p-CORE.setting.pir:60221) (gen\parrot\CORE.setting:11115)
called from Sub 'BUILDALLPLAN' pc 12180 (gen\parrot\stage2\nqp-mo.pir:5473) (gen\parrot\stage2\nqpmo.nqp:1216)
called from Sub 'BUILDALL' pc 7972 (gen\parrot\stage2\NQPCORE.setting.pir:3723) (gen\parrot\stage2\NQPCORE.setting:505)
called from Sub 'bless' pc 7938 (gen\parrot\stage2\NQPCORE.setting.pir:3700) (gen\parrot\stage2\NQPCORE.setting:499)
called from Sub 'new' pc 8718 (gen\parrot\stage2\NQPCORE.setting.pir:4028) (gen\parrot\stage2\NQPCORE.setting:560)
called from Sub 'vivify_for' pc 33342 (src\gen\perl6-metamodel.pir:15179) (gen\parrot\Metamodel.nqp:3096)
called from Sub '' pc 42425 (src\gen\p-CORE.setting.pir:16749) (gen\parrot\CORE.setting:646)
called from Sub 'find_method' pc 3493 ((file unknown):1505) (C:\rakudo\lib\parrot\6.1.0\languages\perl6\site\lib/Grammar/InterceptedGrammarHOW.pm:118)
called from Sub '' pc 25171 (src\gen\perl6-bootstrap.pir:8763) (gen\parrot\BOOTSTRAP.nqp:1679)
called from Sub '' pc 25034 (src\gen\perl6-bootstrap.pir:8705) (gen\parrot\BOOTSTRAP.nqp:1674)
called from Sub '' pc 25174 (src\gen\perl6-bootstrap.pir:8763) (gen\parrot\BOOTSTRAP.nqp:1679)
called from Sub '' pc 25034 (src\gen\perl6-bootstrap.pir:8705) (gen\parrot\BOOTSTRAP.nqp:1674)
...
I don't understand why that is, there must be something wrong with callsame
.
So there are a few ways to deal with it:
find_method
(we still may override add_method
publish_method_cache
as long as we do return callsame
there. Hence, if #10 works out as I hope, it will also solve this issuefind_method
then adding a rule Mu { { die } }
will catch all those calls to non-existing methods, although without giving their name... But at least the backtrace from that shows in which rule the problematic call happened.Tested on Rakudo* 2014.03 on Windows.
I just tried this out, and it appears solved. @meisl Can you confirm?
Yes, confirmed (Rakudo* 2015.06 on Win32)
etc.