00:03 pyrimidine joined 00:20 pyrimidine joined
timotimo so ... i'm apparently trying to reproduce the memory leak that comes from not setting foreign_memory back to 0 ... 00:59
i think i'm not doing it right
maybe 100 evals aren't enough, or the code inside isn't complex enough
TimToady You have to do it with an eval laugh! 01:03
timotimo ==25821== 0 bytes in 37,312 blocks are definitely lost in loss record 1 of 46 01:04
um ... what?
i mean, yeah, it's the function that's supposed to be leaking 01:05
but ... how
geekosaur it thinks something else is referencing that memory 01:06
timotimo um, so how is it "definitely lost", then?
oh
geekosaur 0 bytes definitely lost
timotimo right!
geekosaur the final summary includes memory that it thinks *might* be lost, but until then it doesn't know for certain 01:07
and even then it can't be 100% certain but has some notion of what might be an indirect leak
timotimo well, yeah, of course
you might have sent the pointer to the exact memory location off to a hidden server in the maledives 01:08
geekosaur to some extent, "pointer" is not a concrete thing that can be 100% reliably identified. especially when you are writing a garbage collector! it may do things that cause the emulator to wonder if it's really a pointer or not, so then you have X amount of memory that might be lost through something that it's not sure is a pointer or not 01:11
timotimo right 01:12
geekosaur depending on how the gc is written (and how clever the emulator's heuristics are) it may be more or less certain. if you managed to hit one of the "less certain" cases here, memcheck might be out of its depth
timotimo this isn't gc-managed memory, though :) 01:13
but i suppose gc-managed memory used to point to it
02:48 ilbot3 joined 05:33 pyrimidine joined 05:46 nebuchadnezzar joined 06:35 pyrimidine joined 07:20 domidumont joined 07:25 domidumont joined 07:35 pyrimidine joined 08:29 domidumont joined 08:36 pyrimidine joined 08:45 pyrimidine joined 08:54 pyrimidine joined 09:23 pyrimidine joined 09:35 pyrimidine joined 09:42 pyrimidine joined 10:00 pyrimidine joined 10:10 pyrimidine joined 10:28 pyrimidine joined 10:38 pyrimidine joined 10:47 pyrimidine joined 11:05 pyrimidine joined 11:15 pyrimidine joined 11:33 pyrimidine joined 11:41 pyrimidine joined 11:43 pyrimidi_ joined 11:59 pyrimidine joined 12:03 FROGGS joined 12:11 pyrimidine joined 12:18 pyrimidine joined 12:38 pyrimidine joined 12:48 pyrimidine joined 12:57 pyrimidine joined 13:16 pyrimidine joined 13:25 pyrimidine joined 13:35 pyrimidine joined 13:43 pyrimidi_ joined 14:18 pyrimidine joined 14:45 pyrimidine joined 15:12 pyrimidine joined 15:13 nebuchadnezzar joined 15:24 pyrimidine joined 15:43 pyrimidine joined 15:49 pyrimidine joined 16:15 pyrimidine joined 16:25 pyrimidine joined 16:45 pyrimidine joined 16:55 pyrimidine joined
dogbert17 deafening silence 16:58
timotimo hey dogbert, what's up?
dogbert17 hi timotimo, as always I have a suspicious gist :-) 16:59
is this RT or a MoarVM issue? gist.github.com/dogbert17/dca0295c...e19a6f8279
timotimo ah, that one. i have no idea :| 17:01
i do see that we don't compile uv with debug info when moar's configure has debug turned on, apparently 17:02
i wonder how to tell what stack frame the address belongs to
dogbert17 when I run it now I also get this: moar: 3rdparty/libuv/src/uv-common.c:624: uv_loop_delete: Assertion `err == 0' failed. 17:03
timotimo how nice, it doesn't tell us what the error is, of course 17:04
17:04 pyrimidine joined
dogbert17 seems to come from: void uv_loop_delete(uv_loop_t* loop) { ... 17:05
timotimo right 17:07
but it doesn't say what err is, other than "not 0"
which is like "terminating because of an error: error."
dogbert17 I'll see if I can catch it somehow 17:08
timotimo gdb should be of help 17:09
if you break on the assertion or something
also, maybe you can/have to put -g3 into the CFLAGS inside libuv's Makefile
dogbert17 tryin to set a breakpoint in gdb didn't work. maybe I need this flag of yours then 17:11
timotimo yeah, if it's compiled without debug symbols (as the lack of line numbers in the backtrace suggests) it won't let you do most interesting things 17:12
dogbert17 hmm, which file is the makefile, there are several, hmm 17:13
timotimo good question; i don't know much about how libuv is built 17:14
maybe the internet knows
17:20 domidumont joined 17:23 pyrimidine joined 17:33 pyrimidine joined 17:49 pyrimidi_ joined
dogbert17 FROGGS: you around? 18:09
dogbert17 after a lot of tinkering, the error code is -16, the problem only occurs with the --full-cleanup option 18:27
timotimo ah 18:35
well, full-cleanup issues aren't as bad
FROGGS dogbert17: I am 18:42
dogbert17 FROGGS: I was going to ask about a lib uv assertion failure (backlog a page) but it seems to occur when running with --full-cleanup so maybe it's not important 18:46
FROGGS dogbert17: yeah, seen it a minute ago... I've no clue what we can/should do 18:49
dogbert17 I believe that both timotimo and jnthn has said that --full-cleanup is a bit broken, so maybe the error is caused by some less optimal cleanup code 18:51
19:04 pyrimidine joined 19:16 pyrimidine joined 19:41 mst joined 19:42 pyrimidine joined 19:46 domidumont joined 19:56 pyrimidine joined 20:13 dalek joined 20:20 pyrimidine joined 20:32 pyrimidine joined 20:45 pyrimidine joined 21:09 pyrimidine joined 21:21 pyrimidine joined 21:40 pyrimidine joined 21:51 pyrimidine joined 22:00 pyrimidine joined 22:20 pyrimidine joined 22:30 pyrimidine joined
dalek arVM/compunit_string_mem_share: 549e7d5 | timotimo++ | src/ (4 files):
Revert "Revert "share some string's memory with compunit memory""

This reverts commit b8f72297ba13736efb7e01b28d199b158b18d7df.		 22:31
arVM/compunit_string_mem_share: 406fa15 | timotimo++ | src/6model/reprs/MVMCompUnit.c:
Revert "Revert "prevent access to un-deserialized strings in gc_free""

This reverts commit 47629f3230b784de52f66de19c97f3d3e1e1f29e.
MoarVM/compunit_string_mem_share: c85c15f | timotimo++ | src/6model/reprs/MVMCompUnit.c:
MoarVM/compunit_string_mem_share: make sure previously shared strings get freed
22:48 pyrimidine joined 22:50 pyrimidi_ joined 23:09 pyrimidine joined 23:10 SmokeMachine joined
SmokeMachine hi there! I got a segfault trying to run my perl6 code: gist.github.com/FCO/bb1bb1c0285fcf...8789beb21f 23:12
it occurs some times...
but my code is very big... I'm trying to reduce it... 23:13
23:22 pyrimidine joined 23:47 pyrimidine joined 23:50 d4l3k_ joined 23:59 pyrimidine joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!