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?
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
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
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
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
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;
^

Powered by Cro and the Raku® Programming Language.

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

Thank you!