github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
brrt \o 05:49
samcv o/ 06:01
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
brrt samcv++ 06:17
jnthn morning o/ 09:27
samcv++ # release 09:28
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
brrt ugh, it disappears under MVM_SPESH_BLOCKING, just my luck 16:47
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
[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
[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
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

Powered by Cro and the Raku® Programming Language.

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

Thank you!