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:03 reportable6 left
vrurg [Coke]: do you know if it is golfable to something suitable for a test? 00:12
[Coke] vrurg: it doesn't compile for me, so I can't really golf it. 00:16
... and if it's fixed, I'd have to go back to when it segfaulted, then golf it, then make sure the golf was fixed.
vrurg It works for me both on macos and linux. Do you try it on Windows? 00:17
[Coke] mac. 00:18
might have been a cut and paste error, then.
my windows build is current broken, see previous.
so if it works for you.. then it seems closable.
vrurg fish shell auto-escapes single quotes for me when I paste for `raku -e '...'`. Could it be your problem? 00:19
I'd close it. Would there be a golf for it I'd consider adding a test. But not when it requires a 3rd party module, of course. 00:20
01:03 linkable6 left, reportable6 joined 03:04 linkable6 joined 03:31 evalable6 joined 04:15 codesections5 joined 04:20 codesections left, codesections5 is now known as codesections 04:22 MasterDuke left 04:23 Kaipi joined 04:24 Kaiepi left, Altai-man joined 04:27 bisectable6_ joined, committable6_ joined 04:28 sourceable6_ joined, sena_kun left, committable6 left, bisectable6 left, sourceable6 left, rypervenche left, releasable6 left, notable6 left, ugexe left 04:29 ugexe joined, jdv_ left, jdv joined, rypervenche joined 04:30 Nicholas left, Nicholas joined 04:32 SmokeMachine_ joined, shareable6_ joined 04:33 unicodable6_ joined, coverable6 left, SmokeMachine left, shareable6 left, unicodable6 left, SmokeMachine_ is now known as SmokeMachine, tbrowder left, tbrowder joined 04:41 nativecallable6 left, nativecallable6 joined 04:47 gfldex_ joined, gfldex left 04:48 statisfiable6 left, statisfiable6 joined 04:49 benchable6 left, benchable6 joined 04:50 squashable6_ joined 04:51 squashable6 left 05:01 bloatable6_ joined 05:03 bloatable6 left 05:25 releasable6 joined 05:27 coverable6 joined 05:28 notable6 joined 06:02 reportable6 left 06:05 reportable6 joined 07:22 MasterDuke joined
nine MasterDuke: doesn't the expr jit template for settypename miss the `!`? It has no result, so it should be (template: setdebugtypename! 07:32
Same is true for setbuffersize_fh btw 07:36
And quite a few others. Which makes me wonder if the JIT is smart enough to detect the no-result situation. But then there are examples where the ! is there, despite the only child being a callv 07:38
MasterDuke i think the ! is for when the address of the destination is passed in 07:42
i.e, `\$0` instead of `$0`
so i think the template is correct
nine The only thing the docs say about this is: "The template is marked with a '!' postfix to signal that the expression yields no value and takes care of storing the result itself" 07:43
MasterDuke hm 07:44
github.com/MoarVM/MoarVM/blob/mast...#L508-L526 seems to be the relevant section of the template compiler 07:56
08:31 lizmat_ joined 09:06 lizmat_ left, Geth joined 09:07 TempIRCLogger joined 09:08 gfldex_ is now known as gfldex
gfldex I just hit a heisenbug with MoarVM oops: MVM_str_hash_fetch_nocheck called with a stale hashtable pointer . 09:09
full trace at gist.github.com/gfldex/a62653facd3...19325621f3
lizmat and what is the code? 09:12
gfldex github.com/gfldex/perl6-www-radiobrowser 09:13
nine gfldex: that usually means thread-unsafe hash access in the program 09:26
gfldex: a quick glance at the module shows that it does use threads and hashes 09:27
09:29 Geth left, lizmat_ joined 09:30 Geth joined, TempIRCLogger__ joined 09:31 RakuIRCLogger left, lizmat left, TempIRCLogger left 09:32 lizmat_ left, lizmat joined
gfldex I will check if that solves the problem. 09:59
10:53 linkable6 left, evalable6 left, evalable6 joined
nine In an interesting development the "where does the NativeCall slow down come from?" question morphed into "why the hell did this ever work before?" 11:26
How so? Because when a native sub gets called the first time it should replace its own body with one that doesn't have any setup code anymore. But what gets called is actually not the sub itself, but a clone (because closures...). So while we do replace the original's body, the clone still contains the old one. 11:28
So it really looks like it's more productive to work on the new NativeCall implementation jnthnwrthngtn++ pointed at 11:46
lizmat I'd say: indeed, if I hadn't already said that :-) 11:51
11:55 linkable6 joined 12:03 reportable6 left 12:04 reportable6 joined 12:37 jgaz joined 13:02 jgaz left
dogbert17 it seems as if t/02-rakudo/15-gh_1202.t can fail in two ways, either a SEGV or with 'MoarVM panic: Memory allocation failed; could not allocate 29035875272 bytes' 13:46
it's always the same number 13:47
13:49 jgaz joined 14:04 ggoebel__ left 14:21 jgaz left 15:13 ggoebel__ joined
timo m: say 29035875272.msb 15:56
camelia 34
timo that's multiple gigabytes? tens of gigabytes
m: say 29035875272 / 1024 / 1024 / 1024
camelia 27.0417661145
timo so most likely something's growing without bound 15:58
dogbert17 timo: yes it's strange 16:01
timo do we have a backtrace? 16:05
the SEGV is quite possibly from stack area and heap area running into one another 16:11
just a different way for emory exhaustion when malloc isn't able to report it
dogbert17 timo: let me get one ... 16:12
timo the one fro the malloc panic will probably be more helpful, not sure if the stack actually gets corrupted from the segv if it is what i think it is 16:13
dogbert17 timo: the SEGV version showed up first, gist.github.com/dogbert17/a07d0bb2...66c9d6dc8c 16:31
timo can you print the whole dp and the op? 16:33
dogbert17 timo: gist updated 16:39
timo the values in constants and gc_constants? 16:46
but at least checkee being 0 doesn't seem bad
what does val.o look like, and its STABLE? 16:47
dogbert17 (gdb) p STABLE(val.o) 16:51
Cannot access memory at address 0x10
timo OK, so val.o is null 16:53
that's what's segfaulting here, i imagine
dogbert17 I agree 16:54
trying to run this test under gdb hangs, it doesn't even finish one run 16:55
18:02 reportable6 left 18:06 japhb left 18:09 japhb joined
timo github.com/googleprojectzero/weggli oh my 18:42
MasterDuke interesting 18:48
japhb So is the underlying tree-sitter library, it looks like 19:27
timo ah, you hadn't seen that yet? 19:33
i believe a conference talk about it was linked here some time ago
japhb feigns shock that he might not have perfect memory 19:35
20:04 reportable6 joined 21:04 linkable6 left, evalable6 left 21:05 linkable6 joined 22:05 linkable6 left 22:06 linkable6 joined 22:07 evalable6 joined 22:48 ggoebel__ left 22:49 ggoebel__ joined 23:57 squashable6_ left 23:59 squashable6 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!