00:54 Geth joined 01:38 agentzh joined 02:18 agentzh joined 02:48 ilbot3 joined 03:53 ggoebel joined 05:18 pyrimidine joined 05:57 agentzh joined 07:52 pyrimidine joined 09:11 pyrimidine joined 09:22 pyrimidine joined 09:59 agentzh joined 10:23 pyrimidine joined
Geth MoarVM: 824644ef04 | (Jonathan Worthington)++ | docs/ChangeLog
ChangeLog for 2017.02 release.
 11:44
MoarVM: f319a3659a | (Jonathan Worthington)++ | VERSION
Bump VERSION.
 11:49
timotimo the changelog looks kind of short, huh. 11:52
but the big crash-fixes don't get more than one line, so ... that's probably why 11:53
wait, jnthn
isn't the data section for jit code only in the exprjit?
or did i misunderstand the original commit?
jnthn No 11:54
It's in master
timotimo oh!
neat
jnthn The changelog comes from a git log output :)
It may be used more widely in exprjit, but it fixes a memory leak
(in master)
timotimo i didn't even know! awesome!
(about the leak)
jnthn Which is nice, 'cus I also nailed the other missing bit of Rakudo cleanup this month (in repossession) 11:55
So a perl6-valgrind-m -e '' is now clean with no missing cleanup reported :)
yay, clean spectest
timotimo <3
dogbert17 new release, cool 11:56
timotimo yup yup 11:57
jnthn www.moarvm.org/releases/MoarVM-2017.02.tar.gz 11:58
dogbert17 does any of you have any theories about the harness6 SEGV which was discussed yesterday?
or any ideas as how to debug this further 11:59
jnthn Been pondering how we might prove/disprove the double-release theory
Or hunt down how it happens
dogbert17 listens
jnthn It occurred to me we could set a bit in the object header of decode streams when we free them 12:00
And then whine if we see that added to the worklist
(Something with that header bit set, that is)
dogbert17 like MVM_panic (for whining that is)
jnthn Yeah 12:01
Just like the other checks we do in add_to_worklist when GC debug mode is turned on
dogbert17 if that works do you think enough info will be available or is it 'too late' in the process
I don't know how/where to set that bit I can volunteer to test it 12:03
jnthn If it finds something, it'll be at the very least a further clue of where to look next 12:04
dogbert17 cool
so where should that fix be made (the extra bit and the whine :) 12:06
timotimo did you know that valgrind lets you find pointers to a memory location?
i think we can even do that from code
jnthn timotimo: No? Hmm :)
timotimo so we could do something insane like "when some place frees a pointer, find everything else that points at it"
... "and set the lowest bit to 1 for later complaining"?
having that bit set is probably more trouble than it's worth? 12:07
jnthn Well, if there are any pointers to an object we are about to free then something is already wrong
timotimo true
okay, maybe you can only find things pointing to a location with the gdbserver part of valgrind 12:08
where the heck did i read about that feature? i can't seem to find it 12:10
i must have hallucinated that?! 12:11
12:11 travis-ci joined
travis-ci MoarVM build errored. Jonathan Worthington 'ChangeLog for 2017.02 release.' 12:11
travis-ci.org/MoarVM/MoarVM/builds/202912049 github.com/MoarVM/MoarVM/compare/5...4644ef04e5
12:11 travis-ci left
timotimo bad changelog! bad, bad changelog! 12:12
dalek href="https://moarvm.org:">moarvm.org: ad92bd5 | jnthn++ | / (2 files):
Update website for release.
 12:17
yoleaux2 24 Jan 2017 15:38Z <AlexDaniel> dalek: Please switch this bot to Geth
28 Jan 2017 16:40Z <AlexDaniel> dalek: Please switch this bot to Geth
jnthn www.moarvm.org/ # look, it's secure :) 12:18
Failure above is just a wedge while doing it pull, it seems 12:19
timotimo yeah
Geth moarvm.org: ad92bd5aca | jnthn++ | 2 files
Update website for release.
 12:21
jnthn There we got, another dalek straggler updated :)
*go
dogbert17 wrt the 'double-release' bug, I got a different MVM_backtrace yesterday, dunno if it provides any clues though: gist.github.com/dogbert17/6cb41a1d...8ee886bfe4 12:26
timotimo huh, that's not a double-free or anything, that straight-up crashes 12:27
you don't have that session or the core dump any more, do you? 12:28
dogbert17 nope :( but I can rerun and hope for the best
but yes, this was a SEGV 12:29
jnthn lunch; bbiab
moritz hhvm.com/blog/2017/02/17/region-jit.html 12:30
timotimo it'd be interesting to see what pointer was 0 (or whatever other bad address)
dogbert17 would that have been possible if I had the gdb session running? 12:31
timotimo: if you have some cool hardware nearby you try a 'make spectest HARNESS_TYPE=6 TEST_JOBS=5+' 12:33
timotimo yeah, sure
i will
you just attach gdb to the process via pid after starting it? 12:34
dogbert17 yes
Geth MoarVM/vmhealth: 60e3096605 | (Timo Paulssen)++ | src/moar.c
vmhealth: guard against lack of event loop thread
timotimo when you run it via valgrind, do you do anything in particular to prevent the test files themselves to be valground? 12:35
dogbert17 haven't figured out a way to do that :( 12:38
timotimo hehe. 12:39
well, a clean way would be to allow the harness to get passed a different command to invoke than $*PROGRAM-NAMe or whatever it uses
i wanted to propose using "instrumentation off at program start", but i think that option is only available for callgrind, not for memcheck 12:40
dogbert17 I guess I'll start another run myself as well, can always do something alse while it runs 12:46
timotimo i put in a super evil hack 12:59
class SourceHandler::Perl6 does SourceHandler::Proc {
- submethod BUILD(:@incdirs, Str:D :$!path = ~$*EXECUTABLE) {
+ submethod BUILD(:@incdirs, Str:D :$!path = ~$*EXECUTABLE ~~ s/-valgrind//) {
in lib/Tap.pm6
oops, wants quoting
takes a long time to reach the syntax error stage because it precompiles before doing anything much 13:00
no, it still runs all tests through valgrind 13:04
aha! 13:07
harness6 has a "perlpath" commandline argument
oh wow 13:13
it basically immediately exited with MoarVM panic: use of invalid eventloop work item index -1
but it shows 0 errors for all those processes it started ... 13:14
oh, it is because my perl path was wrong 13:18
the file doesn't exist and therefor it panics
pretty bad
13:19 Ulti joined, Ulti left
timotimo hah 13:23
it's sloooow
i have test jobs set to a high number, but apparently the harness is so slow that it only runs one process at a time :D 13:24
since valgrind causes threads to be serialized (if i recall correctly) it might be a better idea to reduce the number of test jobs a bit
i expect it still leads to a massive decrease in total cpu time used anyway 13:30
and hopefully it also still provokes the failures 13:31
dogbert17 I have been able to run many times with TEST-JOBS=2,3 without anything going wrong 13:35
timotimo OK 13:38
i'm at 6 right now
already is S14
in*
dogbert17 my first run with 5 worked without a hitch 13:39
insidious bug
dogbert17 crash dammit 13:50
14:01 agentzh joined 14:37 camelia joined 15:05 zakharyas joined 15:15 lizmat joined
dogbert17 timotimo: got a SEGV again 15:25
gist.github.com/dogbert17/71bd542c...0bf44dae61 15:27
timotimo how often has it been the decodestream so far? 16:19
dogbert17 timotimo: every time 16:20
timotimo OK, so next step might be to put debug stuff in there ...
dogbert17 any suggestions, i.e. what to look for 16:21
timotimo not really, no :(
dogbert17 and jnthn has fallen asleep :)
timotimo at the point of the free, most of the interesting data has been thrown away
16:21 pyrimidine joined
timotimo (well, not really, just marked as "to be reclaimed", but still ...) 16:21
dogbert17 does that mean we have to back up a step on the stack, to gc_free? 16:25
timotimo i'm interested in the chunks that it deallocates there 16:27
these while loops follow a linked list of chunks that each hold a pointer to a buffer of bytes
dogbert17 yes 16:28
I wonder how often MVM_string_decodestream_destroy is called 16:39
moritz add a printf("42\n"), recompile, run, count :-)
timotimo yeah %) 16:40
also, be extra sure to only count it in the harness, not the testing processes
argh! 16:45
i got it to error, but tmux kept less than 2000 lines of scrollback around >:(
oh, that's just global destruction
OK, that's no problem
ok, turned off --full-cleanup and upgraded the backscroll to 4000 lines 16:47
well, i asked for 5000, but whatever
dogbert17 it's too often for comfort :) 16:48
17:50 ggoebel joined 18:02 agentzh joined 18:34 agentzh joined
timotimo it's not crashing ... 18:53
dogbert17 quite annoying 18:59
are you using gdb or valgrind? 19:01
timotimo valgrind
dogbert17 what about ASAN? 19:02
timotimo *shrug*, could try that 19:03
in theory i could probably run one spec test per core
dogbert17 at least it's faster
timotimo uuuh, weird 19:05
when i pressed ctrl-z, it landed in some process, but not the main one
now i'm running two in parallel 19:06
dogbert17 weird
timotimo and a third for good measure
geekosaur odd. it should go to all of them 19:11
hm, depends. all processes in the foreground process group, but if something is starting them in distinct process groups then all bets are off 19:12
timotimo :D 19:13
19:49 zakharyas joined, pyrimidine joined
timotimo ah, global destruction 21:54
curses!
i don't know why. it's not in the valgrind script .. oh! 21:55
i didn't copy that script, i don't think
since vmhealth is part of a pull request, i feel entitled to a rebase upon latest master 21:59
Geth MoarVM/vmhealth: 9 commits pushed by (Timo Paulssen)++ 22:00
timotimo what combinations of thread state and "is blocked for gc" do we have? 22:53
dogbert17 timotimo, jnthn: got it with ASAN, looks slightly different/better/worse: gist.github.com/dogbert17/eaba7dfc...b1748fbe23 23:12
timotimo oh, huh, that's interesting 23:14
maybe we have some logic error in discarding bytes from a decodestream
like, maybe an off-by-one somewhere
or an edge case like when we had the memory regions for frames 23:15
dogbert17 looks quite suspicious, so part of decodestreams are freed outside of gc? 23:16
timotimo well, a decodestream owns a bunch of buffers 23:17
remember that linked list w etalked about?
dogbert17 yes 23:19
timotimo i would assume that's what got freed in discard_to first, then later in freeing the object itself 23:20
dogbert17 could be that something isn't nulled? 23:25
timotimo potentially 23:26
dogbert17 well at least it feels as if we're zooming in on the right piece of code 23:34
timotimo yup 23:44
i couldn't look closer, people around me were distracting me 23:45
ugh, internet connection is dropping all the time 23:47
dogbert17 uh oh
timotimo so yeah, you looking at this code, too? 23:49
line 76 of decode_stream.c?
dogbert17 I have it in front of me 23:50
that's the line
timotimo yeah 23:51
discard->bytes somehow survives 23:52
dogbert17 but how
timotimo yup 23:53
i mean, we can set it to a bogus value and see what happens 23:55

Powered by Cro and the Raku® Programming Language.

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

Thank you!