01:48 ilbot3 joined 04:54 quester joined 04:57 leedo joined 06:57 quester left
nwc10 good *, #moarvm 08:26
08:52 zakharyas joined
jnthn good * :) 09:16
jnthn has Perl 6 tuits for the rest of the day :)
nwc10 \o/ 09:17
jnthn: the bad news is that even with your thread thingy indirection fixes to MoarVM last week, t/spec/integration/advent2013-day14.t can still hang 09:19
much less often, it seems
but still the same strange one where thread 14 is in epoll
paste.scsys.co.uk/528760
jnthn It's possible that is the event loop thread... 09:20
Yeah, it is 09:21
It looks more like a legit deadlock to me
btw, in the future it'd be useful to do: thread apply all where 09:22
Which gets the stack traces of all the threads, not just the ones that are hopefully the interesting one to know about :)
nwc10: The maybe good news is that the test there does a react/whenever involving a channel, which is also the case in the sometimes-hang of S17-supply/syntax.t 09:46
(Which is what I'm fixing in my branch) 09:47
So if we're lucky it's the same root cause for both.
I can run S17-supply/syntax.t in a loop while a parallel spectest with TEST_JOBS=12 also runs and it doesn't hang ever, which is promising :) 09:49
t/spec/S17-supply/throttle.t still needs me to golf it down, alas :) 09:50
Seems I've uncovered a genuine bug in throttle, which is another of those "how did this ever work" ones 10:10
Merged those fixes 10:28
10:28 dalek joined
jnthn Now going to do a spectest and, concurrent with it, a load of runs of t/spec/integration/advent2013-day14.t :) 10:29
nwc10 I've had one sitting in a loop for about an hour (obviously not with the fixed code) and I can't get it to lock up to do that gdb thing for you 10:36
so will now try new stuff
jnthn OK 10:39
I can't get it to either fwiw
But S17-supply/syntax.t would about one in 20 times
After the fixes I can't make it do it at all
nwc10 no new ASAN barfage 11:29
t/spec/S32-str/encode.rakudo.moar is in RT
ASAN tolerates you, and does not yet feel the need for a reshuffle: cattime.com/trending/17125-larry-th...on-resigns 11:30
(first picture) 11:31
jnthn And no hangs? :) 11:37
nwc10 no, not in two runs
jnthn wonders if Larry the cat voted to remain in the meuw 11:39
Man, which concurrency issue to pick next... 11:42
jnthn analyzes the S32-io/IO-Socket-Async.t occasional failure
nwc10 several of them, at the same time?
also, I admit defeat on trying to follow up on your cat pun. 11:43
(although that actually might be a feed line for this:)_ 11:44
it should be furly easy, but somehow I just can't think of anything that works.
jnthn Seems the failure is because the closing of the server socket happens asyncronously, meaning that the request to open a new listening socket on the same host/port can beat the completion of the closing by a whisker, thus the instability. 11:58
nwc10 jnthn: is it likely that you've addressed the cause of RT #127947 ? 12:15
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=127947
jnthn It's possible, though worth stress-running that test case somewhat too 12:25
dalek arVM: 85b6537 | jnthn++ | src/io/asyncsocket.c:
Fix lost socket listen errors.

For example, "address already in use" could get lost, which is not helpful.
13:08
jnthn And that's why the test wasn't failing in a more useful way when it failed. 13:10
16:24 zakharyas joined 18:05 FROGGS joined 20:49 zakharyas joined, domidumont joined