Welcome to the main channel on the development of MoarVM, a virtual machine for NQP and Rakudo (moarvm.org). This channel is being logged for historical purposes.
Set by lizmat on 24 May 2021.
nine There are up-to-date openSUSE packages for rakudo on s390x. 07:31
lizmat nine: I've not been able to find them on software.opensuse.org ... link? 08:35
nine download.opensuse.org/repositories...5.3/s390x/ 08:44
The repository (for openSUSE Leap 15.3)is download.opensuse.org/repositories...perl6.repo
nine I do not yet build s390x for openSUSE_Factory (the rolling distro). I could - it's just one click to enable that arch, but I don't know if its worth the additional ressource usage 08:46
nine And finally got it to build on Fedora :) 09:00
Module packages need a tweak as well. Have submitted a PR for module2rpm with the fix 09:01
dogbert11 nine: thx for the information wrt github.com/rakudo/rakudo/issues/1920 12:04
I saw that you had merged some fix that seemed related and thought that it might have been fixed 12:05
lizmat thinks she has a fix for #1920 12:44
dogbert11 thinks lizmat deserves +++ :) 12:53
lizmat meh... too early 12:54
at least it isn't always a segfault anymore
dogbert11 small steps are better than no steps :) 12:55
lizmat I had replaced the (require ::($module)) by "lib/$module.rakumod".IO.slurp.EVAL 12:56
that pointed to a stale has access in Rakudo::Internals.EXPORT_SYMBOL
lizmat github.com/rakudo/rakudo/commit/f4cba21c67 12:58
dogbert11 perhaps there are more to it than this 14:37
lizmat yes, I'd say so 14:39
dogbert11 I'm looking through some old stuff in order to see if things have been fixed 14:54
ugexe ❯ raku -e '(1..Inf).race(:batch(1)).map({ require "/Users/ugexe/.rakubrew/versions/moar-blead/lib/Test.rakumod" })'
[1] 31277 segmentation fault raku -e 14:55
and doing the IO.slurp.EVAL gives a error that wasn't present in 2021.12 gist.github.com/ugexe/2d623df785f8...c202c200b0 14:59
i kind of question if anything was fixed or if it was just slowed down enough to make the problem slightly more difficult to shake out 15:01
dogbert11 .seen MasterDuke 15:06
nine There are multiple issues that affect parallel module loading both in MoarVM and Rakudo. 15:22
dogbert11 it seems as if this SEGV har made a comeback: perl6 --profile -e'say "127.0.0.1" ~~ /^ [ <{ 0 .. 255 }> ]**4 % \. $/; say now - INIT now' 15:25
s/har/has/
dogbert11 updated github.com/rakudo/rakudo/issues/2013 with my findings 15:41
there are lots of strange things happening all of a sudden 16:12
for example running valgrind on any program, when moarvm has been built with --no-optimize, makes valgrind complain like crazy with lots of 'Conditional jump or move depends on uninitialised value(s)' 16:14
nine Could be that we lost memory alignment with the move to mimalloc 17:13
lizmat re Rakudo on s390: www.reddit.com/r/rakulang/comments...h/i2bq93l/ 17:25
looks like libffi is too modern?
nine Sounds like they were trying to install openSUSE packages on RHEL. That can work with luck, but it can also run into issues like different versions of libraries being available. 17:29
dogbert11 nine: dunno if it's correct but valgrind seems to think that the problem originates here: 'Uninitialised value was created by a stack allocation at 0x4B696D5: emit_capture_guards (program.c:2241)'
that would be here, github.com/MoarVM/MoarVM/blob/mast...am.c#L2241 17:31
lizmat_ wonders whether this isn't a potential race condition ? 19:41
github.com/rakudo/rakudo/blob/mast...ORTHOW.nqp
nine What would be the race? 19:44
lizmat multiple requires doing the $?PACKAGE.WHO assignment ? 19:45
like the script of #1920 ?
nine If this code is run multiple times, wouldn't it be a different module object each time? 19:54
lizmat it runs several times during module install 20:58
MasterDuke nine, dogbert11: i think that valgrind warning about uninitialized value is correct. if you search for `MVM_VECTOR_.*\(cs->ops`, you'll see that it's PUSHed to, but is never MVM_VECTOR_INITed. so MVM_recalloc is being called without there having first been an MVM_calloc 21:27
oh wait, there's a mix of `cs.ops` and `cs->ops`. ok, `MVM_VECTOR_.*\(cs(->|\.)ops` does show an INIT for `cs.ops` 22:09

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!