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.
00:00 squashable6 left, linkable6 left, evalable6 left, Kaiepi left, gfldex left, rypervenche left, samcv left, japhb left, nine left, nine joined, linkable6 joined, evalable6 joined, squashable6 joined, rypervenche joined, Kaiepi joined, rypervenche left, rypervenche joined 00:02 samcv joined 00:04 reportable6 left 00:05 gfldex joined, japhb joined
[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
02:05 reportable6 joined 02:23 squashable6 left 02:25 squashable6 joined 03:37 squashable6 left 03:40 squashable6 joined 06:02 reportable6 left 07:02 coverable6 left, nativecallable6 left, unicodable6 left, statisfiable6 left, notable6 left, sourceable6 left, evalable6 left, greppable6 left, quotable6 left, tellable6 left, benchable6 left, bisectable6 left, squashable6 left, releasable6 left, committable6 left, shareable6 left, bloatable6 left, linkable6 left, bloatable6 joined 07:04 benchable6 joined, tellable6 joined, sourceable6 joined 07:05 notable6 joined, committable6 joined, releasable6 joined
nine [Coke]: no it's all Azure Pipelines 07:17
08:03 unicodable6 joined
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
09:03 statisfiable6 joined, greppable6 joined
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
10:03 linkable6 joined, squashable6 joined
dogbert17 retries, the bug is still there but does not trigger as often as before 10:03
10:04 bisectable6 joined 10:05 nativecallable6 joined, shareable6 joined
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
11:04 evalable6 joined
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
11:27 nebuchadnezzar left
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
12:03 coverable6 joined
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
12:54 CaCode joined 13:02 quotable6 joined 13:03 reportable6 joined
[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
13:26 linkable6 left 13:28 linkable6 joined
MasterDuke interesting, it looks like passing todo's in subtests aren't reported 13:31
14:05 CaCode left
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
15:16 evalable6 left, linkable6 left, evalable6 joined 15:17 linkable6 joined 15:45 [Coke] left 15:50 [Coke] joined
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
18:02 reportable6 left 19:04 reportable6 joined 19:49 [Coke] left 20:13 [Coke] joined 20:55 rypervenche left 22:05 rypervenche joined 23:42 dogbert17 left 23:44 dogbert17 joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!