|
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
|
|||