github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:02 MasterDuke left 00:12 lizmat joined 00:38 MasterDuke joined 00:45 lizmat left 01:01 Kaiepi left, Kaiepi joined 02:25 lizmat joined 02:27 lizmat left 02:32 lizmat joined 03:36 Kaiepi left, Kaiepi joined 04:23 Kaiepi left, Kaiepi joined 04:51 lizmat left 05:02 lizmat joined 05:32 ggoebel left 05:33 ggoebel joined 05:49 brrt joined
brrt \o 05:49
samcv o/ 06:01
06:05 domidumont joined
Geth MoarVM: 58068ec51a | (Samantha McVey)++ | docs/ChangeLog
Make final fix-ups to ChangeLog to prepare for release
 06:09
MoarVM: 88f3e5ea56 | (Samantha McVey)++ | VERSION
Release 2018.06
06:11 domidumont left 06:12 domidumont joined
brrt samcv++ 06:17
06:23 domidumont left 07:10 robertle joined 07:18 lizmat left 07:21 timotimo left 07:42 brrt left 07:43 zakharyas joined 08:00 lizmat joined 08:07 zakharyas left 08:08 zakharyas joined 08:15 domidumont joined 09:05 zakharyas left 09:26 zakharyas joined
jnthn morning o/ 09:27
samcv++ # release 09:28
10:04 zakharyas left 10:07 zakharyas joined 11:03 zakharyas left 11:07 timo joined, zakharyas joined 11:16 zakharyas left 11:27 timo is now known as timotimo 12:10 committable6 left, committable6 joined 13:03 zakharyas joined 13:25 AlexDani` joined 13:27 AlexDaniel left 13:38 AlexDani` is now known as AlexDaniel 13:55 evalable6 left, evalable6 joined 14:27 MasterDuke left 14:45 domidumont left 15:04 zakharyas left 15:08 zakharyas joined 15:10 robertle left 15:13 brrt joined 15:35 lizmat left 15:46 robertle joined 16:04 zakharyas left 16:14 lizmat joined 16:15 lizmat_ joined 16:19 lizmat left 16:21 zakharyas joined 16:34 lizmat_ is now known as lizmat 16:37 ggoebel left
timotimo so here's a puzzling thing 16:39
in this profile i see that GC run number 6 has 94k bytes promoted and GC run number 7 has 393k bytes promoted 16:40
only problem is:
only about 19k had been retained until then
brrt that is a bit confusing yes
brrt grumbles that *of course* ctxouter breaks in the JIT 16:41
timotimo i'm going to assume it has to do with how we shrink the nursery when we create big objects. maybe we don't factor size reductions in properly 16:42
16:45 zakharyas left
brrt ugh, it disappears under MVM_SPESH_BLOCKING, just my luck 16:47
16:53 ggoebel joined
timotimo is making slightly easier progress on the grant by focusing on the GC tab 17:26
it'll be displaying an "earliest and latest start and end time" for all gc runs, do you think that's actually interesting? 17:28
i might be biased as an internals person, i'd be able to see if one thread is noticably slowing down GC runs, for example
lizmat timotimo: I'd be interested in it :-) 17:33
timotimo i solved the "promoted bytes" mystery: it also counts unmanaged bytes there 17:41
so it shouldn't all go into the same "progress bar" style display
[Coke] moar(24534,0x70001595e000) malloc: *** error for object 0x7fa5513134b0: pointer being freed was not allocated 18:07
*** set a breakpoint in malloc_error_break to debug
Abort trap: 6
got that trying to throw a "start
into doc's xt/examples-compilation
timotimo could very well be you're concurrently modifying something that doesn't like that 18:08
like resizing an array or hash
[Coke] github.com/perl6/doc/blob/master/x...t#L75-L123 - wrapped that in push @jobs, start { ... }, then at the end Promise.allof(@jobs) 18:11
I don't see a hash or array resize in there.
timotimo i wonder if perhaps Test isn't threadsafe? 18:13
it could have been related to lazy lists being consumed from two threads at once, but i don't see that anywhere either 18:14
oh 18:15
hm, try a "my $/" near the start
[Coke] I can always just save the status, and then "finalize" the test in the main thread,.
timotimo i mean inside the start
probably not needed, but that's sometimes the cause of trouble; threads sharing $/
[Coke] huh
timotimo it'd make sense if we have start { } have its own $/ already 18:16
yeah, we probably have that
[Coke] nope, didn't help 18:20
ran it again got a double free.
s/again/with my $//
timotimo your rakudo is probably recent enough, yeah?
can you comment out the stuff from Test? it's a long shot, though ... 18:22
Geth MoarVM: 3ea8f68d3e | (Samantha McVey)++ | src/strings/uthash.h
Use Fibonacci hashing to determine which bucket to put hashv's into

This has an advantage over using ANDing or %ing to get the bucket number because it uses the full bit width of the hash instead of just the last several bits of the hashv.
We multiply the hashv by: max_hashv / phi, where max_hashv is the maximum ... (7 more lines)		 18:41
[Coke] timotimo: 2018.05-55-g95aa77c94 18:45
timotimo: commenting out flunk/pass, etc., same. I'll try to golf it donw. 18:53
dogbert17 [Coke]: I just tried 'make xtest', when running 'xt/examples-compilation.t' something eats filehandles like there's no tomorrow, I've my limit set to 2048 and that's not enough. 19:02
is it possible that there's a 'close' missing somewhere?
[Coke] very possible. 19:03
dogbert17 I get 'Failed to open file /dev/null: Too many open files in block at xt/examples-compilation.t line 110'
[Coke] dogbert17: see the 2 lines where we open devnull ? 19:04
I wonder if those need an explicit close.
dogbert17 I think so yes 19:05
btw, I was running this to see if I could reproduce the problem you're discussing with timotimo 19:06
[Coke]: a couple aof 'close' statements seems to fix the '/dev/null' problem 19:15
[Coke] \o/ 19:23
can you ship that patch?
timotimo could this be a problem of accidentally not reacting to a failed open? 19:25
like, too many open files not being turned into an exception?
dogbert17 [Coke]: will do 19:27
[Code] fixed 19:36
oops, that should be [Coke] not [Code] :) 19:42
19:49 Kaiepi left, Kaiepi joined
[Coke] dogbert17: might be my imagination, but that felt slightly faster. 19:57
dogbert17 [Coke]: did it have any effect on your problem or does it still persist? 20:03
timotimo oh, "the dev null problem" wasn't the crash in question 20:15
brrt .tell samcv we might need to do a new release :-S 20:23
yoleaux brrt: I'll pass your message to samcv.
brrt i screwed up in the implementation of lexprimspec last month
20:24 MasterDuke joined
[Coke] tried to do 'perl6 --profile xt/examples-compilation.t' and got a segfault after the first ok 1; updated rakudo to latest, now it just hangs. 20:27
ah. no, just took a second; segfault. 20:28
this is with perl6/doc on master.
2018.05-123-gcf10780da
timotimo oh, huh 20:30
i didn't even see the moarvm release happen
[Coke] ... and I have a mac, so no gdb. 20:34
timotimo lldb ought to also work
but i haven't tried it yet
[Coke] ok, ran lldb about 30m ago. zzzzz :) 21:02
21:24 brrt left
dogbert17 timotimo: the SEGV seems to occur here: github.com/MoarVM/MoarVM/blob/mast...rp.c#L5397 22:03
hmm, I lied a bit, it should be line 5401 22:09
timotimo that could be caused by prior memory corruption; are you running in gdb or in valgrind? 22:10
dogbert17 I was running gdb, have tried valgrind a few times but with that the error vanishes ... 22:11
samcv oh no 22:12
yoleaux 20:23Z <brrt> samcv: we might need to do a new release :-S
dogbert17 timotimo: asan doesn't help much either, it just says SEGV at the same place 22:14
here's what gdb has to offer: gist.github.com/dogbert17/ade09129...a38f5c7b6f 22:26
[Coke] dogbert17: my segv? 22:28
dogbert17 yes 22:29
on my system it doesn't happen everytime
so once I let it continue, it sort of completed but when the profile output file had reached 150 megs and my swap was almost exhausted I killed the program 22:31
MasterDuke is doing EVAL in threads safe in general?
timotimo: btw, speaking of profile and crashes, any ideas about my question from last night? 22:32
22:35 Kaiepi left 22:53 Kaiepi joined 22:57 robertle left 23:33 greppable6 left 23:34 greppable6 joined 23:43 Kaiepi left 23:48 Kaiepi joined 23:57 lizmat left 23:58 Kaypie joined, quotable6 left, Kaiepi left, quotable6 joined 23:59 lizmat 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!