github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:16 lucasb left 02:21 Kaeipi left, Kaiepi joined 02:24 Kaiepi left 02:25 Kaiepi joined 03:05 Kaiepi left 03:15 frost-lab joined 03:34 Kaiepi joined 04:07 Kaiepi left 06:14 linkable6 left, evalable6 left 06:16 linkable6 joined 06:17 evalable6 joined 06:38 Altai-man joined 07:25 squashable6 left 07:27 squashable6 joined 08:16 Kaiepi joined
nwc10 good *, #moarvm 09:13
09:16 linkable6 left, evalable6 left 09:17 linkable6 joined, evalable6 joined 10:20 sena_kun joined 10:21 Altai-man left
nine We don't have any generic infrastructure for cleaning up (i.e. free memory or whatever) when an exception gets thrown, do we? Just for releasing mutexes. 12:04
timotimo there's throw_adhoc_free, which can be used for any kind of allocation (as long as the pointer's never null) 12:08
(because it stops when it sees the first null pointer)
(i wonder if we leak anything by accident because of this)
nine But nothing where I can plug in a call to MVM_unicode_normalizer_cleanup or MVM_fixed_size_free 12:10
timotimo right 12:14
nine I guess MVM_frame_special_return could be used. But that's quite expensive as it allocates an MVMFrameExtra 12:16
timotimo yeah, we shouldn't do that 12:17
also, we need to make sure we don't accidentally leave stuff in there when we do proper cleanup inbetween
this is more about the C stack than it is about the mvm stack after all
or i may be misunderstanding something 12:18
nine no, that's entirely correct 12:20
12:35 brrt joined
brrt good * #moarvm 12:39
MasterDuke so we need something like MVM_exception_throw_adhoc_run_free? MVM_exception_throw_adhoc_free_willy? MVM_exception_throw_adhoc_freebird? MVM_exception_throw_adhoc_freedom!!!!!? 12:42
nine No, that would require cooperation from every single place that might throw.
We have places that allocate, make a call and several layers down an exception gets thrown 12:43
brrt oh, I'm going to read back for a bit 12:44
Geth MoarVM/asan_fixes: 929eaa22bb | (Stefan Seifert)++ | src/core/frame.c
Fix leak of MVMUnwindData when a frame exit handler throws

If we're unwinding the stack after an exception and one of the frames has an unwind handler that itself throws, like in `try { POST { 0 }; die; }`, we ended up leaking the MVMUnwindData allocated for resuming the initial unwind after running the handler. Since that handler will itself cause an unwind, we don't need to continue the initial unwind, but we still have to free the unwind data.		 13:00
nine Funny how this is clearly a rare and special situation, yet the code to reproduce it is kinda trivial 13:01
jnthn nine: Given special returns will allocate on a callstack in the future rather than needing a malloc/free/frame extras, I'd just use that rather than invent another mechanism 13:03
tellable6 2021-01-08T21:09:33Z #raku-dev <Xliff> jnthn: ^^
jnthn Sending me ^^ on a channel I'm not on isn't too useful :P 13:04
(Assuming that special return will handle it)
nine I think you can safely ignore the ^^ :)
jnthn I suspect the "cleanup on unwind" mechanism for mutexes could also be extended too, though 13:05
oops, cleanup on exception
13:09 brrt` joined
nine special_unwind is a barely working mechanism for this. For one it can only hold one handler. There's also only one special_unwind_data, but MVM_fixed_size_free needs at least 2 arguments. So we'd have to allocate a structure to hold those 13:09
13:11 brrt left, brrt` is now known as brrt
jnthn Yeah, then it's probably better to extend the cleanup on exception thing 13:11
nine We could get away with a fixed number of slots for e.g. things to MVM_fixed_size_free or handlers to call as the number is a property of our code structure and its limited number of possible call stacks. But determining those numbers is hard. 13:13
13:36 frost-lab left
Geth MoarVM/asan_fixes: 08ecb83d91 | (Stefan Seifert)++ | src/spesh/graph.c
Fix leaking PEA deopt_info when inlining an unspecialized frame

If we don't create a spesh candidate from a spesh graph, we have to clean up PEA deopt info when destroying that graph. Same as with other information that usually gets transfered from the graph to the produced candidate.		 13:40
14:19 Altai-man joined 14:21 sena_kun left
nine Oooh... NQPLock's protect method doesn't handle control exceptions, so a return from a protected block will leave the lock in place. The only reason we don't deadlock is that it's usually the same thread taking that reentrant lock again. 15:53
timotimo whoopsie, that's fun 15:56
nine Hm...a CONTROL block doesn't seem to have any effect though 16:09
m: role R { }; (^100).hyper.map({R.HOW.specialize(R, Any)}); 16:27
camelia (timeout) 16:28
nine m: role R { }; (^100).hyper.map({R.HOW.specialize(R, Any)}); 16:41
camelia ( no output )
nine That's better :)
timotimo wonderful 16:45
nine I guess it's about time I prepare a PR with this branch. It contains 17 fixes for memory leaks that can occur in normal operation and a bunch of improvements to --full-cleanup 16:49
MasterDuke nine++ 16:59
17:19 domidumont joined 18:10 brrt left 18:19 sena_kun joined 18:21 Altai-man left 19:02 domidumont left 21:38 sena_kun 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!