01:19 MasterDuke joined 01:57 colomon joined 02:58 ilbot3 joined 03:09 colomon joined 04:27 colomon joined 07:50 TimToady joined 08:13 domidumont joined 08:20 domidumont joined 08:54 TimToady joined 13:04 MasterDuke joined 13:25 Voldenet joined 13:26 brrt joined
brrt good * #moarvm 13:26
i can't compile rakudo on linux with --asan because we're leaking memory from spesh / jit etc 13:29
which makes total sense 13:43
dogbert17 o/ brrt 14:11
does it leak so much that the compile fails?
14:15 MasterDuke joined
brrt with ASAN it does 14:18
dogbert17 hmm, haven't seen that (hav 7 Gigs) 14:22
*have
were you using ASAN_OPTIONS=detect_leaks=0 ? 14:29
14:30 MasterDuke_ joined 15:19 MasterDuke joined 15:51 geospeck joined 17:17 brrt joined
brrt the point of ASAN is that it exits your program with a failure condition and a report if you've leaked memory or done something else you shouldn't 17:21
it's super useful so i'd really prefer if we could build rakudo with it *on* 17:22
anyway.... i may, i hope, have a fix 17:26
.ask jnthn what is our current policy with regards to process cleanup, because i think we leak memory if we shutdown moarvm before the spesh worker is done, and that angers ASAN 17:27
yoleaux brrt: I'll pass your message to jnthn.
Geth MoarVM/memory-leak-fixes: 25dda671d4 | (Bart Wiegmans)++ | src/core/args.c
Fix leak when args bind error would unwind rather than return

The args bind error handler would setup a special-return function and allocate a register for storage, but did not setup an unwind handler. Whenever the frame was then unwound (rather than returned-from), that register would leak. ASAN LeakSanitizer doesn't like that very much.
17:34
dogbert17 brrt++ are there any leaks left? 17:36
17:45 Zoffix joined 18:15 MasterDuke joined
Zoffix Are there any docs for this "register" stuff? GET_REG(cur_op, 10).o GET_REG(cur_op, 2).s GET_REG(cur_op, 0).u64 what are those 10, 2, 0 numbers (register numbers? how to know which one is where the value I want is at?) and what are those .o, .s, .u64 18:28
guessing .object, .string .uint64, but where do those get set?
MasterDuke i think 0 is the first and they go up by two 18:29
ugh, no i think 0 is the destination 18:30
timotimo those are offsets in bytes or something 18:43
GET_REG(cur_op, 0) is "what register is set for the first argument" 18:44
and most ops have their first argument be their "return value"
though there are plenty that don't return at all
GET_REG indexes into the bytecode to see what each parameter specifies as the register it uses - that's what the number is for - and then it uses that as offset into the stack frame (the pointer is likely called "work") 18:45
hope that helps
BBL
Zoffix Ah. Thanks
19:00 geospeck joined 19:05 zakharyas joined 19:47 brrt joined 19:57 greppable6 joined 20:04 MasterDuke joined
Geth MoarVM: 0b9f8090a4 | (Zoffix Znet)++ | src/jit/graph.c
Revert JITting MVM_OP_throwpayloadlexcaller

Doing it causes a segfault when running:
   for ^1000 { EVAL('sub { shift->() }', :lang<Perl5>)({;}) }
After some debugging[^1], it was suggested[^2] we revert the jitting, to unblock release, and figure out what the problem is with it after.
  [1] github.com/rakudo/rakudo/issues/1308
  [2] irclog.perlgeek.de/perl6-dev/2017-...i_15588477
20:47
20:57 committable6 joined 20:58 releasable6 joined, benchable6 joined, quotable6 joined, bloatable6 joined, evalable6 joined, coverable6 joined, reportable6 joined, nativecallable6 joined, bisectable6 joined, unicodable6 joined, squashable6 joined, statisfiable6 joined 21:04 Zoffix left
dogbert17 is this something to worry about? 21:28
src/spesh/inline.c: In function ‘merge_graph’:
src/spesh/inline.c:549:5: warning: this decimal constant is unsigned only in ISO C90 [enabled by default]
inliner->handlers[*inline_boundary_handler].category_mask = MVM_EX_INLINE_BOUNDARY;
^
21:30 brrt joined 22:44 MasterDuke joined 23:47 MasterDuke joined 23:48 AlexDani` joined 23:55 avar joined