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.
[Coke] are we still using appveyor? 01:12
github.com/MoarVM/MoarVM/issues/697 01:13
Nicholas: you're our porter person, right? Is Illumos still a thing or is it dead? github.com/MoarVM/MoarVM/issues/306 01:17
nine [Coke]: no it's all Azure Pipelines 07:17
nine [Coke]++ # cleaning our issue queue 08:15
MasterDuke hm. looks like our expmod behavior isn't exactly the same as python's pow 08:18
m: say expmod(41, -1, 1) 08:25
camelia Error in mp_exptmod: Value out of range
in block <unit> at <tmp> line 1
MasterDuke both python's pow and Perl's Math::BigInt->bmodpow give 0
hm, but that error is coming directly from libtommath 08:27
nine m: say expmod(38, -1, 97) 08:30
camelia 23
nine Looks like at least in Python pow(41, -1, 1) results in undefined behaviour as the docs say "If mod is present and exp is negative, base must be relatively prime to mod." 08:31
MasterDuke but that gives 0, where other combinations throw `ValueError: base is not invertible for the given modulus` 08:33
m: say expmod(42, -1, 7) # like this 08:34
camelia Error in mp_exptmod: Value out of range
in block <unit> at <tmp> line 1
MasterDuke Math::BigInt give Nan for ^^^
i'm building the jvm backend right now to see what it gives for github.com/Raku/roast/blob/master/....t#L25-L36 08:36
nine WolframAlpha agrees that the result is 0 08:37
MasterDuke after the jvm builds i can switch to my gmp branch and see what it says
r: say expmod(42, -1, 1) 08:44
camelia Error in mp_exptmod: Value out of range
in block <unit> at <tmp> line 1
Can't open perl script "/home/camelia/rakudo-j-inst/bin/eval-client.pl": No such file or directory
MasterDuke right, that's why i built it locally. well, jvm backend gives 0
moarvm backend gives 0 with gmp 08:48
nine One more reason to switch to gmp :) 08:50
MasterDuke yeah. only that last windows 64bit vs 32bit bug to figure out... 08:52
it's annoying that you can't todo a test that throws 09:00
MasterDuke huh. why doesn't `#?rakudo.moar todo 'libtommath incorrectly errors and causes a throw instead of giving 0'; lives-ok { die if 42.expmod(-1,1) != 0 }, '42, -1, 1';` report at the end as a passing todo when i run with the gmp branch? 09:24
nine So far I've totally failed at reproducing a failure in t/spec/S12-methods/lastcall.t
dogbert17 hmm, that sounds like the bug I reported a few days ago 09:55
dogbert17 retries, the bug is still there but does not trigger as often as before 10:03
nine I've also tried reroducing the failures in t/05-messages/10-warnings.t that CI showed in the new-special-return PR. Haven't managed to either. Though a normal run ended in a segfault. Sadly, systemd-coredump segfaulted as well trying to process that coredump :( 10:30
MasterDuke so the problem with github.com/MoarVM/MoarVM/issues/1223 is that at the point of the segv github.com/MoarVM/MoarVM/blob/mast...ame.c#L286 , env_size and work_size are 480080 and 480096 10:31
but the MVMCallsStackFrame was just created by MVM_callstack_allocate_frame, which takes MVMuint16s github.com/MoarVM/MoarVM/blob/mast...#L161-L162 10:33
nine Yeah, when reading about 60K variables, I figured it was some 16 bit issue
Thanks for confirming!
MasterDuke because an MVMFrame only has MVMuint16 allocd_work and allocd_env 10:34
but i don't know what the right fix is 10:35
nine Throwing an error, maybe in bytecode verification 10:36
MasterDuke we don't want to allow 60k variables? fwiw, perl runs that script in 2s 10:37
nine We definitely cannot have more than 2^16 registers, that's a fundamental limit of the bytecode format. 10:40
We probably could with a lot of effort support more than 2^16 lexicals. But we'd still have to make sure that we don't lower too many of them to locals. That sounds quite fragile to me 10:42
MasterDuke well, right now we don't support up to 2^16 lexicals. the script only has 60k 10:43
nine does it work with 40k? 10:44
I.e. is it a signedness issue as well?
MasterDuke nope, segv 10:46
after ~40s 10:47
same place 10:49
nine And 30k works? 10:50
MasterDuke segv 10:51
same place 10:52
nine What the? Does it work with 3 variables? :D
MasterDuke same segv with 20k 10:53
`malloc(): invalid size (unsorted)` with 16k 10:54
MVM_malloc -> MVM_string_latin1_decode -> MVM_cu_obtain_string -> MVM_cu_string -> MVM_interp_run 10:55
don't know why size is invalid, it's 7 10:56
f 7 10:58
different segv at 10k 11:02
MasterDuke 8k succeeds 11:04
lizmat
.oO( who would ever need more than 8K )
 11:06
nine Oh, of course! allocd_work and allocd_env are sizes in bytes. So 8K locals * 8 bytes per register is quite close to 2^16 11:09
MasterDuke 3 different segvs. where's the best place to at least put some check and throw for now? 11:14
in deserialize_frames? keep a running count of something and throw if it gets too big? 11:17
Geth MoarVM/fix_segfault_on_many_lexicals: de4d2d4492 | (Stefan Seifert)++ | 6 files
Fix segfaults when a frame has more than 8192 locals

The bytecode format supports 2^16 locals in a frame. However the allocator used 16 bit numbers for sizes, i.e. bytes. Since a register is 8 bytes large, we could only allocate enough space for 2^13 registers. Fix by using 32 bit numbers for size calculations.		 11:19
nine With this the 60k example succeeds. Going over 2^16 ends in "Annotation segment overflows end of stream" 11:21
MasterDuke that's nicer 11:22
what is the spesh_nodelay stuff?
nine Oh, that's unrelated. Good thing I pushed into a branch 11:23
When trying to reproduce those other bugs I thought that we could make nodelay configurable to get speshed versions between no information and really good statistics and provoke issues that way 11:24
Didn't help though. But it still could be useful
MasterDuke ah, yeah 11:26
Geth MoarVM/fix_segfault_on_many_lexicals: cadafe8ef2 | (Stefan Seifert)++ | 4 files
Fix segfaults when a frame has more than 8192 locals

The bytecode format supports 2^16 locals in a frame. However the allocator used 16 bit numbers for sizes, i.e. bytes. Since a register is 8 bytes large, we could only allocate enough space for 2^13 registers. Fix by using 32 bit numbers for size calculations.
nine Having reviewed the new allocation code really made ^^^ quite easy 11:27
Geth MoarVM/fix_segfault_on_many_lexicals: 24392a32c2 | (Stefan Seifert)++ | 4 files
Fix segfaults when a frame has more than 8192 locals

The bytecode format supports 2^16 locals in a frame. However the allocator used 16 bit numbers for sizes, i.e. bytes. Since a register is 8 bytes large, we could only allocate enough space for 2^13 registers. Fix by using 32 bit numbers for size calculations.
Fixes GH #1223		 11:32
MoarVM: niner++ created pull request #1588:
Fix segfaults when a frame has more than 8192 locals
dogbert17 nine++, you're on a roll 11:35
as far as the lastcall issue is concerned I have set: #define MVM_NURSERY_SIZE (20 * 1024) 11:39
nine not a single failure so far 12:30
Geth MoarVM/dispatcher-replace-arg-syscall: ed0c8ec068 | (Timo Paulssen)++ | 5 files
create MVM_callsite_replace_positional and use it
dogbert17 are you running: while MVM_SPESH_NODELAY=1 MVM_SPESH_BLOCKING=1 ./rakudo-m -Ilib --ll-exception t/spec/S12-methods/lastcall.t; do :; done 12:31
nine Yes, except for --ll-exception 12:32
dogbert17 bizarre, perhaps I have messed something up in my installation 12:33
Geth MoarVM/dispatcher-replace-arg-syscall: 68b8f429f4 | (Timo Paulssen)++ | src/disp/program.c
initialize vector to known size, MasterDuke17++
 12:38
timo jnthnwrthngtn: as nine pointed out yesterday, we'll want to see if the MVM_callsite_* ops should all attempt an intern at the end of their operation, as their documentation comments suggest 12:40
dogbert17 k 4 - lastcall meant nextsame failed, no deferal happened
Can only use manipulate a capture known in this dispatch
in method doit at t/spec/S12-methods/lastcall.t line 39
in block <unit> at t/spec/S12-methods/lastcall.t line 46
timo with --ll-exception you'll also see the line of the dispatcher program where it happens 12:41
dogbert17 timo: all the data I have can be found here, github.com/MoarVM/MoarVM/issues/1580 12:42
timo can you tell me what's at gen/moar/BOOTSTRAP/v6c.nqp:5248 ? is it just the -> $capture { line? 12:44
dogbert17 5247 # us to handle `callwith`). 12:46
5248 -> $capture {
5249 # We put a sentinel value into the resume state in the case that we have
timo well, that's weird 12:47
getting the entire tree of captures could be potentially interesting here 12:48
but it should look trivial
the one track argument call that i can see in that block is the one that is called directly on $capture 12:50
MVM_dump_bytecode(tc) can give a tiny bit of insight 12:51
[Coke] I am very surprised to find that some random bug I tickled last night that was in the queue for ages is now fixed. :) 13:06
nine++ MasterDuke++
Geth MoarVM: 24392a32c2 | (Stefan Seifert)++ | 4 files
Fix segfaults when a frame has more than 8192 locals

The bytecode format supports 2^16 locals in a frame. However the allocator used 16 bit numbers for sizes, i.e. bytes. Since a register is 8 bytes large, we could only allocate enough space for 2^13 registers. Fix by using 32 bit numbers for size calculations.
Fixes GH #1223		 13:25
MoarVM: cbed18a68c | niner++ (committed using GitHub Web editor) | 4 files
Merge pull request #1588 from MoarVM/fix_segfault_on_many_lexicals

Fix segfaults when a frame has more than 8192 locals
MasterDuke [Coke]++ for testing old issues
MasterDuke interesting, it looks like passing todo's in subtests aren't reported 13:31
nine MasterDuke: weird-errors is a good place for that test :) 14:09
MasterDuke heh, yeah, i wanted one that was marked slow and it also seemed appropriate 14:10
[Coke] :) 14:22
dogbert17 timo: do you want me to dump the bytecode from the breakpoint line, i.e. src/disp/program.c:677 14:27
MasterDuke huh. i did a perf record of that 60k variables script and the most expensive function was MVMHash_gc_mark 14:29
dogbert17 timo: gist.github.com/dogbert17/f81c6141...83ed2c1414 14:30
timo the bytecode does show that it's literally passing the value of the first passed argument in that syscall 16:07
oh, whats in that variable? could it be NULL for some reason? 16:08
i think the syscall mechanism checks for that tho

Powered by Cro and the Raku® Programming Language.

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

Thank you!