| IRC logs at
Set by AlexDaniel on 12 June 2018.
01:20 Altai-man_ joined 01:22 sena_kun left 02:26 leont left 03:21 sena_kun joined 03:23 Altai-man_ left 04:23 bloatable6 left, bisectable6 left, sourceable6 left, greppable6 left, committable6 left, coverable6 left, shareable6 left, releasable6 left, reportable6 left, nativecallable6 left, squashable6 left, quotable6 left, unicodable6 left, notable6 left, statisfiable6 left, benchable6 left 04:24 shareable6 joined, nativecallable6 joined, squashable6 joined, committable6 joined 04:25 releasable6 joined, reportable6 joined, coverable6 joined, unicodable6 joined, notable6 joined 04:26 statisfiable6 joined, bloatable6 joined, sourceable6 joined, benchable6 joined, bisectable6 joined, quotable6 joined, greppable6 joined 05:20 Altai-man_ joined 05:23 sena_kun left 07:21 sena_kun joined 07:23 Altai-man_ left 09:20 Altai-man_ joined 09:23 sena_kun left
nine Looks like even with there's still some issue with finalizers and nested runloops. 09:37
I'll try to find a proper fix in the evening. 09:38
Please if you want to do a release before I got that fix, commit this workaround: 09:39
This restores the old behaviour which is also broken, but in a more benign way (missed DESTROY calls and potential memory leaks instead of segfaults) 09:40
11:21 sena_kun joined 11:23 Altai-man_ left 12:09 leont joined 13:20 Altai-man_ joined 13:23 sena_kun left 14:15 lucasb joined
nine I get it :) Funny how obvious such issues are once you find out what's going on. 15:08
15:21 sena_kun joined 15:23 Altai-man_ left
lizmat waits in anticipation for the punchline 15:27
Geth_ MoarVM: 3806735a4b | (Stefan Seifert)++ | src/core/frame.c
Fix even more obscure crashes when returning from a native callback

The special_return or special_unwind handler may schedule a finalizer call for the current runloop. If we are already in the top most call frame of the runloop, we need to replace the thread_entry_frame with the finalizer call. Otherwise we won't run the special code for ending the runloop when the finalizer returns.
nine lizmat: this ^^^ 15:49
But of course, there's yet another regression :( Reproducible with MVM_SPESH_NODELAY=1 MVM_SPESH_BLOCKING=1 perl6-gdb-m -Ilib t/data_in_module.t 16:07
Apparently caused (or uncovered) by which I pushed by accident
(hence the rather short commit message) 16:08
Ok, looks like this is not that bad. It's purely a side effect MVM_SPESH_NODELAY=1. With that, we never even run a non-optimized version of the code but start right away with the JIT compiled one. The JITed code however does not contain the check if the native library is loaded. 16:29
After all the non-JITed code would have long done this and we want to be fast.
So even changing the spesh threshold from 1 to 2 when MVM_SPESH_NODELAY=1 gets rid of the issue. So I conclude that this will never appear under normal circumstances and I can relax :) 16:30
The part I don't understand is why this doesn't break any other test files with MVM_SPESH_NODELAY=1 MVM_SPESH_BLOCKING=1. 16:33
Anyway, seems like we've regained stability and got rid of a couple bugs. A release with this would be very welcome :) 16:37
17:21 Altai-man_ joined 17:23 sena_kun left 17:46 AlexDaniel` left
lizmat nine++ 18:26
18:35 lucasb left
nine Apparently the couple of weeks even payed off :) All green on the first try: 18:49
lizmat whee!
18:57 AlexDaniel` joined 19:21 sena_kun joined 19:23 Altai-man_ left
discord6 <sjn 🇳🇴> Yay! 19:48
20:17 AlexDani` joined 20:18 AlexDaniel left 21:21 Altai-man_ joined 21:23 sena_kun left 22:52 dogbert11 joined 22:54 dogbert17 left 23:01 Kaiepi left 23:02 Kaiepi joined 23:10 dogbert17 joined 23:12 dogbert11 left 23:21 sena_kun joined 23:23 Altai-man_ left