00:47 colomon joined 01:24 vendethiel joined 04:09 vendethiel joined 07:02 Ven joined 07:03 vendethiel joined 07:06 zakharyas joined 07:14 Ven joined 07:29 FROGGS joined 07:46 Ven joined 08:31 Ven joined 09:22 vendethiel joined 10:26 tadzik joined 10:27 tadzik joined 10:48 Ven joined 11:35 Ven joined
JimmyZ docs.libuv.org/en/v1.x/#documentation # better docs for libuv, FYI 12:21
12:35 vendethiel joined 13:04 vendethiel joined 13:19 Ven joined 13:33 vendethiel joined 14:45 vendethiel joined 15:15 Ven joined 15:20 vendethiel joined 15:30 Ven joined 15:59 vendethiel joined
dalek arVM: f3512a8 | paultcochrane++ | src/6model/reprs/MVMCode.c:
Free allocated variable before returning

Coverity scan pointed out that the variable `ann` wasn't being freed before the function MVM_code_location() returned. This should fix this issue. The NQP tests all pass after having made this change (there aren't any MoarVM tests), so it seems that everything still works as expected.
17:07
arVM: 522e168 | timo++ | src/6model/reprs/MVMCode.c:
Merge pull request #203 from paultcochrane/pr/fix_MVMCode_resource_leak

Free allocated variable before returning 88592c7 | jnthn++ | src/ (3 files): More missing frees of bytecode annotations.
timotimo [ptc]++
17:07 synbot6 joined 18:01 Ven joined 18:18 FROGGS joined
jnthn f3512a8 looks legit, but I now think we should check other callsites for that function :) 19:23
timotimo yeah
i can do that
jnthn already found 2 here :) 19:26
(and written le patches) 19:27
timotimo i see 19:28
timotimo at least the one in the profiler and spesh seem "hot" 19:30
so that's very good 19:31
though since the data is apparently always extremely short-lived, we may want to allocate it on the stack of the caller and populate it in the callee
jnthn maybe, though none of it is hot path, afaik
timotimo yeah 19:32
just a little tingling sensation in my nose :P
:-P
20:23 Ven joined