- Project: https://github.com/vrurg/raku-Vikna/tree/for-comma-debug
- Rakudo stack is built with
./Configure.pl --gen-moar --gen-nqp --backends=moar– nothing specific
- Just in case, as the project needs chained dispatchers, there is a branch
v-dispatcherfor it in either the main rakudo repo or in my fork at https://github.com/vrurg/rakudo/tree/v-dispatchers
- A breakpoint is set in
lib/Vikna/EventHandling.rakumod. Basically any line within
!run-ev-loopmethod is ok. Last time it was line 58.
- The script I'm using for testing is
- The debugging can be configured with option start suspended set to any on or off, makes no difference. I usually start suspended, so my scenario is based on this.
- Fresh start, no previous runs/debug sessions.
- Click the bug. Get debug window with moar command line.
- Click 'Resume Program'. Get the first subtest done (it's ran asynchronously to the main thread, so this is fine). The debugger focuses the breakpointed line.
- Click 'Resume Program' again. The debugger highlights the line next to the breakpoint (??). MoarVM outputs "marking thread 6 unblocked, but its status is already NONE.".
- Last click on 'Resume' is really the last. Comma freezes. 'moar' process eats 100% CPU but kindly reacts on SIGINT by exiting. At this point Comma can only be shut down with SIGKILL.
Sometimes I get a freeze instantly after the first 'Resume'.
Overall, it feels like Comma doesn't tolerate abrupt terminations of
moar in certain situations. It's nothing but a speculation, but it looked as if it is freezing mostly when there is no reply to a request sent over to the debug process.