Grammar::Tracer loops on missing rules

lumimies commented 12 years ago


$ perl6 -e 'use Grammar::Tracer; grammar Foo { token TOP { <foo> } }; say Foo.parse("1234")'
TOP
|  foo
|  |  Mu
|  |  |  Mu
|  |  |  |  Mu
|  |  |  |  |  Mu
|  |  |  |  |  |  Mu
|  |  |  |  |  |  |  Mu
|  |  |  |  |  |  |  |  Mu
|  |  |  |  |  |  |  |  |  Mu
|  |  |  |  |  |  |  |  |  |  Mu
|  |  |  |  |  |  |  |  |  |  |  Mu
|  |  |  |  |  |  |  |  |  |  |  |  Mu
|  |  |  |  |  |  |  |  |  |  |  |  |  Mu
|  |  |  |  |  |  |  |  |  |  |  |  |  |  Mu
|  |  |  |  |  |  |  |  |  |  |  |  |  |  |  Mu

etc.

meisl commented 10 years ago

This seems to be a bug in the Grammar implementation itself. ~~It also happens without Tracer or Debugger - you just don't see it (but rather go and kill your program after a while).~~ (not quite right, see below).

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 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! (again, not quite right).

meisl commented 10 years ago

What I wrote above is not entirely right.

if we don't muck around with method lookup at all, then there's the correct No such method 'foo' exception thrown.
neither is method wrapping as such the culprit (be it with lambda or with Routine.wrap).
if we don't override 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.
HOWEVER, if we do override 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 yields

maximum 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:

don't override 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 issue
if we really have to override find_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.

hoelzro commented 9 years ago

I just tried this out, and it appears solved. @meisl Can you confirm?

meisl commented 9 years ago

Yes, confirmed (Rakudo* 2015.06 on Win32)

jnthn / grammar-debugger

Grammar::Tracer loops on missing rules #1