MoarVM panic when testing Red (CONTROL blocks)

[AlexDaniel]

See this ticket #2640.

Basically there was an attempt to fix the regression in this commit: 71a19c6

However, exactly on that commit MoarVM panic can be observed:

The following candidates are already installed: Red
===> Searching for: Red
===> Found: Red:ver<0.0.2>:api<0> [via Zef::Repository::LocalCache]
===> Testing: Red:ver<0.0.2>:api<0>
t/00-meta.t ........................ ok
t/01-basic.t ....................... ok
t/02-tdd.t ......................... ok
t/03-sqlite.t ...................... ok
t/04-blog.t ........................ ok
t/05-ticket.t ...................... ok
MoarVM panic: Trying to unwind over wrong handler
t/06-better-map.t .................. 
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/1 subtests 
t/07-optimizer.t ................... ok
t/08-best-tree.t ................... ok
t/09-alternate-relation.t .......... ok
t/10-alternate-relation-modules.t .. ok
t/11-join.t ........................ ok
t/12-types.t ....................... ok
t/14-result-seq-update.t ........... ok

Test Summary Report
-------------------
t/06-better-map.t                (Wstat: 256 Tests: 0 Failed: 0)
  Non-zero exit status: 1
  Parse errors: Bad plan.  You planned 1 tests but ran 0.
Files=14, Tests=251, 106 wallclock secs ( 0.10 usr  0.01 sys + 156.38 cusr  7.15 csys = 163.64 CPU)
Result: FAIL
===> Testing [FAIL]: Red:ver<0.0.2>:api<0>
Failed to get passing tests, but continuing with --force-test

[jnthn]

I checked out latest Red and ran its tests on Rakudo HEAD, and they all pass for me.

[jonathanstowe]

Yep looks good here too.

[AlexDaniel]

That's good, though we probably will end up with no test for this…

[AlexDaniel]

The panic is still there, it's not fixed… I'm not sure when this issue was introduced, in the last run of Blin it was bisected to this commit 3d3578b. It probably means that on HEAD it is flapping, but on 2018.12 it was working consistently.

[lizmat]

Cannot see a panic, but do see failure: $ zef install Red ===> Searching for: Red ===> Searching for missing dependencies: DBIish, DB::Pg ===> Searching for missing dependencies: NativeHelpers::Blob, LibUUID, epoll ===> Testing: NativeHelpers::Blob:ver<0.1.10>:auth<github:salortiz> # Failed test 'Defined st pointer 0' # at t/02-cstruct.t line 49 Invocant of method 'Numeric' must be an object instance of type 'NativeCall::Types::Pointer', not a type object of type 'NativeCall::Types::Pointer'. Did you forget a '.new'? in method Numeric at /Users/liz/Github/rakudo.moar/install/share/perl6/sources/8660F65A7B3492675BB3B2058DB30E411A4C4E54 (NativeCall::Types) line 31 in block <unit> at t/02-cstruct.t line 53 # Looks like you planned 35 tests, but ran 14 # Looks like you failed 1 test of 14 ===> Testing [FAIL]: NativeHelpers::Blob:ver<0.1.10>:auth<github:salortiz> Aborting due to test failure: NativeHelpers::Blob:ver<0.1.10>:auth<github:salortiz> (use --force-test to override)

…

On 18 Feb 2019, at 23:10, Aleks-Daniel Jakimenko-Aleksejev ***@***.***> wrote: The panic is still there, it's not fixed… I'm not sure when this issue was introduced, in the last run of Blin it was bisected to this commit 3d3578b. It probably means that on HEAD it is flapping, but on 2018.12 it was working consistently. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[jonathanstowe]

I think that's #2703

[AlexDaniel]

Seems to be still happening. @jonathanstowe can you double check?

[jonathanstowe]

Yep. Will do.

[jonathanstowe]

Well. I think we have a flapper here:

[jonathan@coriolanus Red]$ zef test . --debug
===> Testing: Red:ver<0.0.2>:api<0>
Testing with plugin: Zef::Service::TAP+{<anon|1>}
t/00-meta.t ........................ ok
t/01-basic.t ....................... ok
t/02-tdd.t ......................... ok
t/03-sqlite.t ...................... ok
t/04-blog.t ........................ ok
t/05-ticket.t ...................... ok
t/06-better-map.t .................. ok
t/07-optimizer.t ................... ok
t/08-best-tree.t ................... ok
t/09-alternate-relation.t .......... ok
t/10-alternate-relation-modules.t .. ok
t/11-join.t ........................ ok
t/12-types.t ....................... ok
t/13-roles.t ....................... ok
t/14-result-seq-update.t ........... ok
t/15-union.t ....................... ok
t/16-result-seq-bool.t ............. ok
t/17-create-related-pars.t ......... ok
All tests successful.
Files=18, Tests=288,  119 wallclock secs
Result: PASS
===> Testing [OK] for Red:ver<0.0.2>:api<0>
[jonathan@coriolanus Red]$ perl6 -v
This is Rakudo version 2018.12-311-gd6563816e built on MoarVM version 2018.12-110-g04982f6e9
implementing Perl 6.d.
[jonathan@coriolanus Red]$ 

Similar result using prove6 too.

[AlexDaniel]

@jonathanstowe is my understanding correct that this issue did not exist before?

[jonathanstowe]

I've only seen it once, so yes.

[AlexDaniel]

Actually, I'm struggling to reproduce this myself. I think it's mostly OK.

[AlexDaniel]

OK, I'm not sure about this one. It failed with MoarVM panic in Blin three times in a row. There's something wrong.

[AlexDaniel]

Looks like it always happens in t/06-better-map.t.

[AlexDaniel]

And again, I can't reproduce it locally. @dogbert17 maybe you can try something?

[AlexDaniel]

<dogbert17> AlexDaniel: I had a look at R#2665, I can't get the test to panic on its own, it only panics when trying to install the module via zef

@dogbert17++! Indeed, it can be reproduced rather easily with zef install Red.

[jonathanstowe]

Hmm,
I've seen stuff like this that happens only the first time it is compiled with Lumberjack too.

[ugexe]

$ prove -e 'perl6 -I.' t/
t/00-meta.t ........................ ok
t/01-basic.t ....................... ok
t/02-tdd.t ......................... ok
t/03-sqlite.t ...................... ok
t/04-blog.t ........................ ok
t/05-ticket.t ...................... ok
t/06-better-map.t .................. MoarVM panic: Trying to unwind over wrong handler
t/06-better-map.t .................. Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/1 subtests
t/07-optimizer.t ................... ok
t/08-best-tree.t ................... ok
t/09-alternate-relation.t .......... ok
t/10-alternate-relation-modules.t .. ok
t/11-join.t ........................ ok
t/12-types.t ....................... ok
t/14-result-seq-update.t ........... ok

Test Summary Report
-------------------
t/06-better-map.t                (Wstat: 256 Tests: 0 Failed: 0)
  Non-zero exit status: 1
  Parse errors: Bad plan.  You planned 1 tests but ran 0.
Files=14, Tests=251, 34 wallclock secs ( 0.09 usr  0.02 sys + 46.37 cusr  1.99 csys = 48.47 CPU)
Result: FAIL

$ perl6 -v
This is Rakudo version 2018.12-320-g9a87b568f built on MoarVM version 2018.12-117-gdcafbc4c7
implementing Perl 6.d.

This happens every single run on the Linux and OSX machines I tested on.

[AlexDaniel]

I think @dogbert17++ figured it out:

• Red module on CPAN differs from the master branch on github: https://colabti.org/irclogger/irclogger_log/perl6-dev?date=2019-02-26#l164
• CPAN version fails reliably while the latest code from master branch does not.
• Backtrace: https://gist.github.com/dogbert17/ff0c5ab85bedb88e9c38ea4e93942697
• The backtrace seems to be similar to this ticket: MoarVM panic with CONTROL block MoarVM/MoarVM#572 (golf: CONTROL { }; warn "foo")
• And indeed, there are CONTROL blocks in ResultSeq.pm6

In terms of the upcoming release, it seems that we're hitting a known bug, but also @FCO can release a new version on CPAN and the issue will somewhat go away.

Not a blocker, phew. Thanks to everyone involved. ♥

EDIT: oops, sorry for the ping, @jonathanstowe!

[AlexDaniel]

I'll keep this open so that we have a ticket in Rakudo repo, but for any discussion see MoarVM/MoarVM#572