|
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
|
|||