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.
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
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
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
gfldex I will check if that solves the problem. 09:59
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
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
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
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

Powered by Cro and the Raku® Programming Language.

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

Thank you!