github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
nine Some times you just can't seem to make progress... Running the otherwise working code with MVM_SPESH_LOG ends in this: MoarVM oops: Too many levels of inlining popped 08:08
nine This is interesting: the sp_guardconc that blows up is the first one after a nativecallinvoke. And one that's running for quite a while with many other calls (even to the same NativeCall site) in between. 10:15
Furthermore tc->cur_frame changes from before entering that call to after it returns. Could be moved by the GC. The frame is on the heap after all 10:17
nwc10 gdb hardware watchpoint time?
(whcih I assume you were already doing. just wanted to say something, because this stuff is hard and I can't help) 10:18
nine But the GC seems innocent. When I increase the nursery size from the puny to 1 GiB tc->cur_frame stays the same from before to after. But it's effective_spesh_slots is cleared. 10:22
So, it's rr time! 10:23
nwc10 every pirate's favourite debugging tool 10:33
nine So the native function does a callback. For this we start a new runloop which processes the call. The call does a rebless which causes a MVM_spesh_deopt_all. That deopt is what clears the spesh_cand and effective_spesh_slots on the frame of the outer runloop. 10:38
This would be fine, but the callback_handler restores tc->interp_cur_op and tc->interp_bytecode_start after the callback to the values they had before, essentially negating the deopt changes. Only that now we're missing the spesh info on the frame. 10:39
I wonder why we actually need to restore those values... 10:43
nine MVM_SPESH_INLINE_DISABLE=1 makes the issue go away! 12:53
brrt \o 15:06
nwc10 .tell brrt o/ 16:20
tellable6 nwc10, I'll pass your message to brrt
timotimo o/ 17:33
sena_kun timotimo: hey! 17:35
timotimo: how are you?
timotimo not fantastic 17:36
how about you?
sena_kun timotimo: so so, I guess... having a final exam with lots of complex topics to pass, but things are doable anyway. 17:37
timotimo as long as your creeps are pumping energy into the controller, you'll gain global control level, which persists across respawns 17:38
sena_kun timotimo: I hope things will become better for you.
timotimo haha, wrong channel
sena_kun _creepy_ 17:39
timotimo i should catch up all my local checkouts, and make a new JSON::Fast release
japhb timotimo: What's new in JSON::Fast land? Which is to say, what would the release gain us? 17:46
timotimo bug fix for some specific unicode trouble
japhb Ah, nice 17:47
timotimo i believe the starfield_scroller.p6 doesn't even have a moving player thingie yet, though? 17:49
wrong window again 17:50
nine Seems like I added enough hacks so the deopt will affect the outer frame of the callback. But it still leads to very strange errors 18:41
nine Well, one thing is sure: the nativecallinvoke op needs to be marked :deoptallpoint and :maycausedeopt as that's exactly what can happen in a callback 20:34
Alas that does not fix my issue :/ It doesn't even change anything about the "Can't find deopt all idx" I'm seeing with the frame that contains the nativecallinvoke 20:37
nine Finally! 21:04
tc->cur_frame->return_address = cur_op; before the call to MVM_nativecall_invoke seems to do the trick. Deopt needs that return address 21:05
nine Feels like I have an 80 % understanding of all the parts involved and I've got a pile of hacks that turn this segfaulting test into a passing one. I guess that's good enough to call it a day :) 21:12
sena_kun nine++ 21:13

Powered by Cro and the Raku® Programming Language.

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

Thank you!