2018-08-10 Toast results / 2̶9̶ 18 burns

[zoffixznet]

https://toast.perl6.party/

[AlexDaniel]

See comment below for a newer version of the table

Previous similar ticket: #2121

• ✓ – potentially OK
• ✗ – clearly broken

Module	Status	Comment / Resolution
6pm	?
App::Platform	?
App::redpanda	✓	dep on Getopt::Type
App::snippet	?	weird and scary error in Pluggable module, but can't reproduce
Archive::SimpleZip	✓	dep on CompUnit::Util
CompUnit::Util	✗	rakudobug #2201
Cro::TLS	✓	flap
DOM::Tiny	✓	most likely rakudobug #2201
Data::StaticTable	✓	ticketed flaps
FastCGI::NativeCall::PSGI	?
Getopt::Type	✗	Previously submitted PR
HTTP::Parser	?
Hematite	✓	dep on HTTP::Parser
MongoDB	✓	toaster flop
Monitor::Monit	✓	toaster flop
OAuth2::Client::Google	?
PDF	?	can't reproduce, was running it in a loop
PDF::Content	✓	dep on PDF
Path::Router	✗	previously opened rakudobug #2126
ProblemSolver	✓	flapping tests, PR
Pythonic::Str	✓	toaster flop
Slippy::Semilist	✓	toaster flop
Sparrowdo::VSTS::YAML::Build	?
Sparrowdo::VSTS::YAML::Cordova	?	can't reproduce
Template::Anti	✓	dep on DOM::Tiny
US-ASCII	✓	toaster flop
WWW::vlc::Remote	✓	dep on DOM::Tiny
Web::RF	✓	dep on HTTP::Parser
WebSocket	✓	dep on HTTP::Parser
App::Assixt	?
App::Nopaste	?
Audio::Icecast	?
CSS::Module	?
Concurrent::BoundedChannel	?
Distribution::Builder::MakeFromJSON	?
FanFou	?
Farabi6	?
META6::bin	?
Math::Model	?
Matrix::Client	?
Operator::grandpa	?
PDF::Lite	?
Pastebin::Gist	?
Stream::Buffered	?
zef	?

[AlexDaniel]

Some things were fixed in MoarVM. However, there's some discussion about SEGVs. I think after that is sorted out we'll need to run toaster again.

[jnthn]

I'm utterly failing to catch the SEGV under the debugger (or even in any situation when running them outside of the spectests). There's a fairly small range of commits that could have introduced it, and they do show up quite reliably under test/spectest, so I'll just figure out which commit it is and revert it.

[jnthn]

Finally caught it in gdb:

Thread 2 "moar" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff6351700 (LWP 20096)]
MVM_spesh_usages_remove_unused_deopt (tc=tc@entry=0x68d930, g=g@entry=0x7fffec1d3ec0) at src/spesh/usages.c:340
340	                if (du_entry->deopt_idx >= 0 && !deopt_used[du_entry->deopt_idx]) {
(gdb) where
#0  MVM_spesh_usages_remove_unused_deopt (tc=tc@entry=0x68d930, g=g@entry=0x7fffec1d3ec0) at src/spesh/usages.c:340
#1  0x00007ffff76cfc7b in MVM_spesh_optimize (tc=tc@entry=0x68d930, g=g@entry=0x7fffec1d3ec0, p=p@entry=0x7fffec275010) at src/spesh/optimize.c:2862
#2  0x00007ffff76c4419 in MVM_spesh_candidate_add (tc=tc@entry=0x68d930, p=0x7fffec275010) at src/spesh/candidate.c:81
#3  0x00007ffff76d4f05 in worker (tc=0x68d930, callsite=<optimized out>, args=<optimized out>) at src/spesh/worker.c:16
#4  0x00007ffff76444e1 in thread_initial_invoke (tc=0x68d930, data=<optimized out>) at src/core/threads.c:59
#5  0x00007ffff76203ae in MVM_interp_run (tc=0x798, tc@entry=0x68d930, initial_invoke=0x7fffec749b48, invoke_data=0x207fffec669cf0, invoke_data@entry=0x68f0a0) at src/core/interp.c:92
#6  0x00007ffff7644566 in start_thread (data=0x68f0a0) at src/core/threads.c:87
#7  0x00007ffff6b666ba in start_thread (arg=0x7ffff6351700) at pthread_create.c:333
#8  0x00007ffff718c41d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
(gdb) p du_entry
$1 = (MVMSpeshDeoptUseEntry *) 0x207fffec669cf0
(gdb) p du_entry->deopt_idx
Cannot access memory at address 0x207fffec669cf0
(gdb) p *du_entry
Cannot access memory at address 0x207fffec669cf0

[jnthn]

What, I don't even...computers...how do they work... sigh

So when GCC started randomly segfaulting on some of my MoarVM builds as I was trying to figure out which commit was to blame, I wondered if maybe something really odd was going on in the Linux VM I develop in at home. So, reboot (host and VM for good measure), recompile everything...run test and spectest...no sign of segfaults at all.

Sorry for the noise. Go forth and re-toast. :-)

[AlexDaniel]

Previous similar ticket: #2121

• ✓ – potentially OK
• ✗ – clearly broken

Module	Status	Comment / Resolution
ANTLR4::Grammar	✓	some kind of a flop
Algorithm::Trie::libdatrie	✓	hash randomization flop, previously submitted PR
App::Assixt	✓	dep on Config::TOML
App::Platform	✗	dep on nqp ops, Raku/nqp@d844d6f
App::redpanda	✓	dep on Getopt::Type
Config::DataLang::Refine	✓	dep on Config::TOML
Config::Parser::toml	✓	dep on Config::TOML
Config::TOML	✗	the issue is now resolved
Cro::SSL	✓	toaster flop
DB::Model::Easy	✓	dep on DBIish
DBI::Async	✓	dep on DBIish
DBIish	✓	toaster flop
Getopt::Type	✗	is rw issue, previously submitted PR
HTTP::Parser	✗	rejected rakudobug #2215, PR
Hematite	✓	dep on HTTP::Parser
Sustenance	✓	dep on Config::TOML
Web::RF	✓	dep on HTTP::Parser
WebSocket	✓	dep on HTTP::Parser
Distribution::Builder::MakeFromJSON	✓	installs fine
Inline::Perl5	✓	installs fine
Operator::grandpa	✓	installs fine
PDF::Lite	✓	installs fine

[jnthn]

The Config::TOML error looks rather like one I got when doing a MVM_SPESH_BLOCKING=1 run of the spectests this afternoon. I hunted it down and fixed it in MoarVM/MoarVM@da9123a.

On MoarVM HEAD I can't reproduce the Config::TOML error. I went back before my fix, and it failed in the same way as on Toaster. I did a few runs with each commit and it reliably failed before MoarVM/MoarVM@da9123a and reliably passed afterwards. So, looks like that one got fixed while the toaster was running. :-)

[jnthn]

Ran ANTLR4::Grammar manually including MVM_SPESH_BLOCKING=1 just to stress it a bit. Ran fine. The error looks like it somehow failed to find the test file at all though, which is odd.

[jnthn]

Also glanced at the App::Platform one; it is using an nqp::op, which is not something we commit to the stability of. So that's not a blocker.

[AlexDaniel]

@jnthn yeah, it's likely this Raku/nqp@d844d6f

Would be nice to submit a PR for that module, but this https://github.com/7ojo/perl6-platform says “This repository has been archived by the owner. It is now read-only.”

[patrickbkr]

@AlexDaniel I think the reason https://github.com/7ojo/perl6-platform is read only is because 7ojo moved his repos to gitlab: https://gitlab.com/tavu/perl6-platform . At least that's what is says here: https://github.com/7ojo

[AlexDaniel]

I submitted a merge request here: https://gitlab.com/tavu/perl6-platform/merge_requests/32

Basically it changes nqp::getstrfromname to parse-names. However, parse-names is only available in rakudo 2017.03+, so it's not a proper fix…

Anyway, that's it for this ticket. Closing.

[AlexDaniel]

Argh… it's not that simple: http://colabti.org/irclogger/irclogger_log/perl6?date=2018-08-15#l762

I'll work on hardcoding the characters directly into .t files…

[AlexDaniel]

OK better PR here: https://gitlab.com/tavu/perl6-platform/merge_requests/33/diffs