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:08 reportable6 left 00:25 timo left 01:11 reportable6 joined 02:36 linkable6 left, evalable6 left 02:39 linkable6 joined, evalable6 joined 03:14 frost joined 03:15 frost left 03:20 frost joined 03:23 frost left 03:26 frost joined 04:26 releasable6 left, quotable6 left, coverable6 left, squashable6 left, bloatable6 left, benchable6 left, evalable6 left, nativecallable6 left, bisectable6 left, notable6 left, reportable6 left, statisfiable6 left, tellable6 left, sourceable6 left, committable6 left, linkable6 left, shareable6 left, unicodable6 left, greppable6 left, coverable6 joined, bloatable6 joined, notable6 joined 04:27 nativecallable6 joined 04:28 evalable6 joined, releasable6 joined, sourceable6 joined, linkable6 joined, greppable6 joined 04:29 benchable6 joined 05:26 unicodable6 joined 05:27 reportable6 joined, squashable6 joined 05:28 bisectable6 joined, shareable6 joined 06:10 reportable6 left 06:27 quotable6 joined 06:28 tellable6 joined, statisfiable6 joined 07:27 committable6 joined 08:12 reportable6 joined 10:08 linkable6 left, evalable6 left
Geth MoarVM: MasterDuke17++ created pull request #1676:
Jit even more *_u versions of ops		 10:15
MoarVM: review: github.com/MoarVM/MoarVM/pull/1676
MasterDuke17++ created pull request #1677: Root orig since MVM_frame_capturelex can allocate
 10:16
10:43 Shane_ joined, Shane_ is now known as Shane__
11:09 evalable6 joined
Geth MoarVM: df8d3bb97b | (Daniel Green)++ | src/disp/syscall.c
Root orig since MVM_frame_capturelex can allocate

Found by the check-roots gcc plugin.		 11:37
MoarVM: 1b9c96389c | MasterDuke17++ (committed using GitHub Web editor) | src/disp/syscall.c
Merge pull request #1677 from MasterDuke17/add_missing_MVMROOT_in_syscall
11:44 sena_kun left 11:45 sena_kun joined 12:07 reportable6 left 13:07 evalable6 left 13:09 reportable6 joined, linkable6 joined 13:31 discord-raku-bot left, Techcable left, tbrowder left, Nicholas left, leedo left 13:32 discord-raku-bot joined, Techcable joined, tbrowder joined, Nicholas joined, leedo joined 13:33 discord-raku-bot left, Techcable left, discord-raku-bot joined, Techcable joined
Geth MoarVM: MasterDuke17++ created pull request #1678:
Some nativeref optimizations and fixes		 14:40
[Coke] anyone have any pointers on how to get useful info out of MVM_GC_DEBUG? blog post or doc file somewhere? 14:58
MasterDuke "Use the source, Luke." 15:07
15:08 evalable6 joined
MasterDuke i.e., i don't know of any documentation so just search for the message in the source and see if i can figure anything out in context 15:08
[Coke] Roger that. 15:14
Geth MoarVM: MasterDuke17++ created pull request #1679:
Restore jitting of sp_getarg_[inso]		 15:23
MasterDuke does a callsite have a "static" method/sub name? 15:52
m: sub foo(uint :$b) { $b + 1 }; my uint $b = 0; for ^1_000_000 { $b = foo(:$b) }; say $b 16:02
camelia Unexpected named argument 'b' passed
in sub foo at <tmp> line 1
in block <unit> at <tmp> line 1
MasterDuke m: sub foo(uint :$b) { $b + 1 }; my uint $b = 0; for ^10 { $b = foo(:$b) }; say $b
camelia 10
MasterDuke ^^^ some missing *_u param handling in spesh 16:03
dogbert17 I guess that two threads trying to change an MVM_VMarray at the same time is a BAD thing? 16:06
i.e. like this gist.github.com/dogbert17/c1bcbfc6...ad38be3f7a 16:08
nine Yeah, changing the array size concurrently is bound to fail. 16:13
The only thing that's ok is writing to or reading from an existing array slot, i.e. reading and modifying without changing size 16:14
MasterDuke yeah. i have a very old WIP PR that converts MVM_VMArray to use the FSA and a single block of memory for storage and metadata. it should enable nicer errors in this case (like we now have for concurrent modification of a hash)
dogbert17 nine: any ideas, without using rr :), to figure out which array this might be? this is when running the example github.com/MoarVM/MoarVM/issues/1675 on Moar 2021.12 16:15
I wanted to see how things looked without mimalloc 16:16
nine Just dump the backtrace of one of those threads 16:17
in gdb
break on __asan::ReportGenericError 16:18
dogbert17 aha
are we talking about MVM_dump_backtrace? 16:19
nine yes
dogbert17 ok, let me try
16:20 linkable6 left, evalable6 left 16:21 evalable6 joined
dogbert17 (gdb) b __asan::ReportGenericError 16:21
Function "__asan::ReportGenericError" not defined
tries __asan_on_error@plt instead ... 16:23
MasterDuke got above failing example to work. using hllboxtype_i though, not sure if a hllboxtype_*u* is actually required though... 16:25
dogbert17 nine, MasterDuke: gist.github.com/dogbert17/ab921bcf...6ae0a85d75 16:26
nine Oh....what happens if you eagerize the "errors.md.tmpl" xx 1_000? 16:29
[Coke] so it looks like GC_DEBUG has more panics that might get triggered (but they didn't for me in this case) 16:31
16:31 Shane__ left
dogbert17 like this ? ("errors.md.tmpl" xx 1_000).eager.join... 16:32
lizmat was talking about eager the other day, something about not dispatching correctly
nine Ah, no, that's probably not it.
dogbert17 perhaps unrelated, colabti.org/irclogger/irclogger_lo...-03-01#l76 16:33
[Coke] switched back down to MVM_GC_DEBUG=1, no panics still. Back to golfing, I guess. 16:36
dogbert17 [Coke]: have you made the nursery smaller? 16:37
[Coke] ... no 16:50
I can do that.
dogbert17 [Coke]: look at the file src/gc/collect.h 16:54
#define MVM_NURSERY_SIZE 4194304 // set this to a lower value, e.g. 16384 or something 16:56
17:14 discord-raku-bot left, discord-raku-bot joined 17:18 discord-raku-bot left 17:19 discord-raku-bot joined
[Coke] dogbert17: should I also have MVM_GC_DEBUG enabled at the same time? 17:21
nine Yes. I'd set MVM_GC_DEBUG 2 as a good compromise between performance and catching GC issues (on a reasonably fast machine) 17:24
[Coke] (oof. don't reduce the nursery size and *then* try to install a bunch of dependencies) 17:30
18:08 reportable6 left
[Coke] ok. running with gc-debug and small nursery size... nothing. I get the original failure node, no extra info 18:09
japhb Kindof marginal in terms of being on-topic, but does the nursery need to be page-aligned? If so, it might be worth changing the define to be a product to clearly indicate that. (e.g. `#define MVM_NURSERY_SIZE (4 * 4096) # 4 - 4K pages`) Of course, if that's not so, don't make it seem to be. :-) 18:17
s:2nd{'#'} = '//'; 18:19
sourceable6 japhb, No idea, boss. Can you give me a Code object? Output: 4===SORRY!4=== Error while compiling /tmp/j3rIpmI6g8ā¤Confusedā¤at /tmp/j3rIpmI6g8:1ā¤------> 328ā4nd{'#'} = '//';ā¤ expecting any of:ā¤ whitespaceā¤
japhb Hah
18:20 linkable6 joined
[Coke] any other suggestions before I go back to trying to golf? 18:29
nine japhb: no, shouldn't matter 18:58
It's start must be aligned and it is, but the size is free
19:10 reportable6 joined
dogbert17 [Coke]: what kind of failure do you get? 19:15
[Coke] "it just stops" 19:21
I am looping over like 50 directories, print something out when I start a directory... and it prints one and then just stops.
no error, no exception, nothing from --ll-exception. Here's a BT: 19:22
gist.github.com/coke/ae63d0a6efee6...f449632780
Looks like a GC run is trying to free something it shouldn't 19:23
if I build moar with --nomimalloc, error goes away
so far seems to require using several modules (including a local one), an indir( run()) call...
I have a nested for dir() -> $ ... { for dir() -> ... if I try to remove that and hardcode the first 5 entries or so, it just processes them all. So loading File::Find appears to be part of it, so far. 19:39
ugexe dir() is lazy, so nested dir() calls that aren't eager can lead to too many file handles being open 19:43
(although maybe thats not the case for your actual code) 19:44
[Coke] Trying to unwind just one of the dirs also avoids the issue
ugexe change each dir() to dir().eager and see if it helps
then again what im suggesting should explicitly tell you that you ran out of handles, and not just dead lock 19:47
ah sorry thought this was #raku 19:48
[Coke] Sorry 19:53
(no effect, btw, still fails) 19:54
20:48 evalable6 left, linkable6 left 20:49 evalable6 joined, linkable6 joined
MasterDuke am i going crazy? why can i not add a new op? add them to oplist, add them to interp.c, run tools/update_ops.raku, build and install moarvm. then go to nqp and try to configure+install (before i do `make m-bootstrap-files`) and i get an insta `Unhandled exception: Bytecode validation error at offset 20, instruction 4: 21:05
operand type 32 does not match register type 64 for op hintfor in frame <dependencies+deserialize>`
oh, they have to be added at the end don't they... 21:06
nine Or replace one of the DEPRECATED 21:17
MasterDuke `MVMArray: read_buf out of bounds offset 2495132133400 start 0 elems 48 count 4`...i suspect a signed/unsigned discrepancy... 21:56
22:01 linkable6 left, evalable6 left 22:02 linkable6 joined 22:03 evalable6 joined 23:39 discord-raku-bot left 23:40 discord-raku-bot 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!