github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:07 MuRmAn_27 joined 00:26 discoD left 00:30 MuRmAn_27 left 00:50 sena_kun joined 00:52 Altai-man_ left 01:12 Kaeipi left, Kaeipi joined 01:19 Altai-man_ joined 01:21 sena_kun left 01:27 farcas1982regreg left 02:49 Kaiepi joined, Kaeipi left 03:04 Kaiepi left 03:11 Kaiepi joined 03:20 sena_kun joined 03:21 Altai-man_ left 03:56 Util joined 04:30 farcas1982regreg joined 05:19 Altai-man_ joined 05:22 sena_kun left 06:25 Kaiepi left 06:26 Kaiepi joined
nwc10 good *, #moarvm 06:27
jnthn o/ 07:16
07:20 sena_kun joined 07:21 Altai-man_ left
nwc10 jnthn: so round here, procurement is having a bit of a 'mare. Beer is no problem, but it seems that SodaStream refil cylinders can't be obtained for love nor money. 07:28
moritz have you tried pure hatred instead of love or money? :D 07:31
jnthn Ooh, that's a curious thing to have a shortage of 07:32
Hm, it's hard to drink coffee while wearing a mask... 07:38
(Got workers here doing some kitchen stuff) 07:39
nine straw?
jnthn Don't have one of those around. I think "go to another room once this test case passes" will be the chosen option :) 07:42
MasterDuke github.com/MoarVM/MoarVM/blob/mast....c#L81-L84 should really be also setting `body.ssize` to `result_pos * sizeof(MVMCodepoint)`, correct? 08:18
08:29 zakharyas joined
MasterDuke timotimo: hm. github.com/MoarVM/MoarVM/pull/689/...d2f76b3cfe is now giving these errors gist.github.com/MasterDuke17/77ce7...9dbc358661 08:49
makes me think some values are off, but i haven't figured out which ones yet
09:19 Altai-man_ joined 09:21 sena_kun left 11:16 MasterDuke left 11:20 sena_kun joined 11:21 Altai-man_ left 12:10 Voldenet joined, Voldenet left, Voldenet joined 12:15 patrickb joined 12:35 MasterDuke joined
dogbert17 It seems as if the reduced number of 'Scalar replacements', according to the profiler, in [Tux] canary test are caused by github.com/rakudo/rakudo/commit/ae...accfc1e47f 13:06
Does that make any sense or is the profiler, after this commit, not reporting the number of scalar replacements properly? 13:07
13:19 Altai-man_ joined 13:22 sena_kun left 13:23 Kaiepi left 13:39 Kaiepi joined
MasterDuke timotimo: whoops, github.com/MoarVM/MoarVM/pull/689/...dbc21b3R92 13:58
doh, still get the same error after fixing that
timotimo "We went looking everywhere, but couldn’t find those commits." 14:04
14:19 zakharyas left 14:23 zakharyas joined
MasterDuke i force pushed over. but i had `((MVMArray *)out)->body.ssize = result_pos * result_pos * sizeof(MVMCodepoint);` instead of `((MVMArray *)out)->body.ssize = result_pos * sizeof(MVMCodepoint);` 14:29
timotimo haha, oops 14:30
MasterDuke guess i accidentally hit 'p' twice 14:31
timotimo prolly, yeah 14:32
that's why we really need proper physical units in C
the one-dimensional buffer can't be of b²!
though in this case, sizeof would return a b and result_pos would be what? probably unitless? 14:33
nine With proper physical units, you would never do result_pos * sizeof(MVMCodepoint) because MVMCodepoint would be the unit of result_pos and they would be inseparably joined in the first place. 15:03
Or it's as you said that sizeof(MVMCodepoint) is a number of bytes and result_pos is just a scalar... Then they would indeed not have helped
I think I'm gonna remove all MVMROOTs of MVMCompUnits. There seems to be only one place ever allocating them and it does so in gen2 directly. It's not even possible to clone them. 15:08
In exchange, I'm gonna add MVMROOTs to all places handling MVMStaticFrames, because if they come from freshcoderef they may actually still be in the nursery. 15:09
jnthn Sounds reaonable. 15:11
nine Oh, another one of these devious GC violations: MVM_ASSIGN_REF(tc, &(static_frame->common.header), static_frame_body->spesh, MVM_repr_alloc_init(tc, tc->instance->StaticFrameSpesh));
Well, it would be if not for the MVM_gc_allocate_gen2_default_set(tc); 15:12
I wonder if there's a good way to mark such false positives
jnthn I think that was the one where putting it directly into gen2 saved a good number of inter-gen refs 15:13
(Like, enough there was a measurable win)
15:20 sena_kun joined 15:21 Altai-man_ left
nine Surprisingly even a static_frame's body.static_code is vulnerable, due to.....freshcoderef 15:40
Which means that there's even a but in MVM_frame_invoke: github.com/MoarVM/MoarVM/blob/mast...ame.c#L474 15:41
16:17 Kaiepi left 16:18 Kaiepi joined 16:20 farcas1982regreg left 16:36 patrickb left
MasterDuke is this correct? github.com/MoarVM/MoarVM/pull/689/...e0f3a2R111 16:40
or should it be just ssize (i.e., not ssize * repr_data->elem_size)? 16:41
17:15 zakharyas left
nine I'd guess it's correct 17:17
17:19 Altai-man_ joined 17:21 sena_kun left 17:34 MasterDuke left 17:35 patrickb joined
nine It is kinda ironic that I'm on this branch containing 10 fixes to GC issues and now my rakudo build fails with "MoarVM panic: Internal error: invalid thread ID 28351 in GC work pass" 17:53
Which is exactly what our Windows builds stumble over
It's even reproducible 17:54
[Coke] I mean, that might be good news that you'd be able to fix it without having a windows box. 17:55
nine Nah, I just forgot a MVM_gc_root_temp_pop before a return 18:09
Geth MoarVM/gcc_root_checker_plugin: 6 commits pushed by (Stefan Seifert)++ 18:19
MoarVM/gcc_root_checker_plugin: 62dc6c7f7b | (Stefan Seifert)++ | src/core/frame.c
Fix possible access to fromspace in MVM_frame_binddynlex

MVM_frame_find_contextual_by_name may cache the result which in turn may trigger an allocation of an MVMFrameExtra. Thus we need to root the name and value pointers in case they get moved by the GC.		 18:29
nine With that frame.c looks clean 18:30
There are so many traps that are so easy to fall into. Both for missing an MVMROOT and for adding one when it actually isn't necessary. Like github.com/MoarVM/MoarVM/blob/mast...ads.c#L126 18:50
Ordinarily MVM_gc_mark_thread_blocked can enter the GC. But this is the one case when it will definitely not, because child_tc is not yet in the instance's thread list 18:51
[Coke] nine; are you catching unnecessary ones or missing ones right now?
nine Both. I'm fixing the missing ones and adding comments to the places where I identified false positives. 18:52
Geth MoarVM/gcc_root_checker_plugin: a39b63c99b | (Stefan Seifert)++ | src/core/hll.c
Fix possible access to fromspace in MVM_hll_set_config

MVM_intcache_for may allocate, so better do it while config_hash is still MVMROOTed.		 18:55
MoarVM/gcc_root_checker_plugin: 9b011b0332 | (Stefan Seifert)++ | src/core/nativecall_dyncall.c
Fix possible access to fromspace in MVM_nativecall_invoke

If we're calling a C++ constructor the result CPPStruct is allocated during processing of the arguments. Thus it may be moved by a GC run triggered by MVM_gc_mark_thread_blocked or MVM_gc_mark_thread_unblocked and needs rooting.		 19:04
19:07 MasterDuke joined 19:20 sena_kun joined 19:22 Altai-man_ left 19:24 lucasb joined 19:27 vesper left, vesper11 joined
Geth MoarVM/gcc_root_checker_plugin: 6038316725 | (Stefan Seifert)++ | src/debug/debugserver.c
Fix possible access to fromspace in MVM_debugserver_notify_unhandled_exception

request_all_threads_suspend can trigger a GC run via MVM_gc_mark_thread_blocked, so we need to root the ex pointer.		 19:34
MoarVM/gcc_root_checker_plugin: fd27422864 | (Stefan Seifert)++ | src/debug/debugserver.c
Fix possible access to fromspace in request_all_threads_resume

request_thread_resumes may trigger a GC run via MVM_gc_mark_thread_blocked, so we need to ensure the cur_thread pointer gets updated.
MoarVM/gcc_root_checker_plugin: 833339332c | (Stefan Seifert)++ | 4 files
Fix possible access to fromspace in various async I/O functions

This error got copy&pasted 7 times. A local type casted variable was used but not rooted. Since MVM_repr_box_str will allocate and therefore may trigger a GC run, the local variable could have become outdated.		 19:52
nine Could we ever find ourselves with an STable in the nursery that has a not yet deserialized HOW? 20:10
Geth MoarVM/gcc_root_checker_plugin: f9ca5cb053 | (Stefan Seifert)++ | src/6model/reprs/Decoder.c
Fix possible access to fromspace in MVM_decoder_take_bytes

Allocating the result buffer may trigger a GC run during which the decoder pointer may become outdated. Move the allocation to after we're done with the decoder, as we don't need the result buffer until then anyway.		 20:11
nine And could we ever find ourselves with an STable in the nursery that has a not-yet-deserialized method_cache? That seems more unlikely. But if not, why do we MVMROOT st in MVM_serialization_finish_deserialize_method_cache? 20:13
Geth MoarVM/gcc_root_checker_plugin: f3cdc75751 | (Stefan Seifert)++ | src/6model/serialization.c
Fix possible access to fromspace in throw_closure_serialization_error

We're actually entering the GC unconditionally, so if closure points to the nursery it will get outdated.		 20:27
MoarVM/gcc_root_checker_plugin: 863e4104f2 | (Stefan Seifert)++ | src/moar.c
Fix possible acces to fromspace in MVM_vm_event_subscription_configure

The startup_time string will be accessed after we allocate the number holding the time
21:18 patrickb left 21:19 Altai-man_ joined 21:22 sena_kun left 23:20 sena_kun joined 23:21 Altai-man_ left

Powered by Cro and the Raku® Programming Language.

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

Thank you!