|
01:11
FROGGS_ joined
03:36
doublec joined
05:38
domidumont joined
05:44
domidumont joined
06:35
zakharyas joined
07:19
domidumont joined
07:25
zakharyas joined
07:47
zakharyas joined
08:39
zakharyas joined
08:55
brrt joined
|
|||
| jnthn | timotimo: MSVC gives this warning: c:\consulting\moarvm\src\spesh\manipulate.c(268) : warning C4716: 'MVM_spesh_manipulate_split_BB_at' : must return a value | 11:37 | |
| [Coke] | just tried to build moar (from nqp, from rakudo) using strawberry perl+git bash; got a "unknown OS 'msys'") | 13:07 | |
| RT #125501 | |||
| synopsebot6 | Link: rt.perl.org/rt3//Public/Bug/Displa...?id=125501 | ||
| dalek | arVM: 10ae72c | jnthn++ | src/6model/reprs/ConcBlockingQueue.c: Mark blocked around some more lock acquisitions. |
13:15 | |
| arVM: 583bb52 | jnthn++ | src/gc/orchestrate.c: Make a panic message clearer in its origin. |
|||
| arVM: 5b64f88 | jnthn++ | src/6model/reprs/ConcBlockingQueue.c: Fix various cases of out-dated pointer reads. When we come back from being blocked, GC may have taken place. This means that objects may have moved, and any interior pointers we hold must be updated. |
|||
| jnthn | Those get things at least somewhat more reliable. Turns out that - at least so far - the bugs I expected to uncover in GC orchestration weren't actually there. | 13:18 | |
| timotimo | oof | 13:24 | |
| lizmat | jnthn: is there a reason that ShapedArrayCommon role has a .plan method? (whereas we removed that everywhere else) | 13:25 | |
| jnthn | lizmat: 'cus at the time it was added, it hadn't been removed everywhere else, perhaps? | 13:26 | |
| And got left behind during the removal? | |||
| lizmat | ok, then I'll remove it :-) | ||
| timotimo | .plan is really oldschool | ||
| i wouldn't mind a revival | |||
| lizmat | the only thing it now dies, saying it's illegal on shaped arrays | ||
| jnthn | It's possible it got removed in nom while I was working in a branch :) | 13:27 | |
| mst | lizmat: maybe somebody subclassed it into Dildo and without a .plan it wouldn't've had finger support? | 13:30 | |
| lizmat looks outside and sees a crow land on the garage | 13:31 | ||
| dalek | arVM: bf8fc05 | jnthn++ | src/6model/reprs/ (2 files): A couple of further missing rootings. From auditing the various places a thread GC-blocks itself. |
13:40 | |
| timotimo | that could certainly improve stability | 13:41 | |
| jnthn | All of those help a little | 13:45 | |
| I'm still seeing the odd issue | |||
| Hmm. I wonder if things may go bad if a uv_sem_t moves around in memory over its lifetime :) | 13:49 | ||
| We hold locks and condvars at a LoI to prevent that | |||
| nwc10 | "LoI" - Level of Indirection? | 13:50 | |
| jnthn | aye | ||
| yeah, this seems like an improvement | 13:54 | ||
| timotimo | ... i don't understand this. i thought we already have the LoI in place to prevent trouble, so what change have you just made that seems like an improvement? %) | 13:55 | |
| dalek | arVM: 11e02fe | jnthn++ | src/6model/reprs/Semaphore. (2 files): Hold uv_sem_t at a level of indirection. So its location in memory doesn't change over its lifetime. Turns out that it doing so can make pthreads very sad indeed. |
13:57 | |
| jnthn | That one :) | 13:58 | |
| We didn't have it in place for semaphores | |||
| Probably 'cus we don't, afaik, actually use them inside of CORE.setting, just provide them for end users needing low level stuff | |||
| jnthn checks that | |||
| oh no, we use it in ThreadPoolScheduler.pm | 13:59 | ||
| timotimo | a-ha! | ||
| good, good | |||
|
14:01
zakharyas joined
|
|||
| jnthn is running the thing that once could barely get it right 10 times in a row 1000 times | 14:11 | ||
| Worked out fine :) | 14:21 | ||
| timotimo | yays! | 14:32 | |
| jnthn has moved on to investigating a spectest that sometimes hangs, that sadly was not magically fixed by this | 14:34 | ||
| timotimo | that just means it's still useful :) | ||
|
14:35
FROGGS joined
|
|||
| jnthn | Oh, it'll let me close an RT and the non-semaphore fixes will have also improved overall stability | 14:36 | |
| timotimo | \o/ | 14:37 | |
| jnthn | Does anyone know in GDB how you can thread apply all [2 commands here]? | 15:08 | |
|
16:30
zakharyas joined
17:37
domidumont joined
|
|||
| japhb | jnthn: SO MANY PLUSSES for today's fixes. I'd been writing single-threaded Perl 6 code for quite a while because I was just hitting too many odd failures; if your comment from 4 hours ago of two orders of magnitude threading reliability improvements is representative, I'm about to have a very good day. :-) | 18:11 | |
|
18:12
mst joined
|
|||
| nwc10 | jnthn: this still deadlocks: paste.scsys.co.uk/528614 | 18:49 | |
| no, wait, *that* ons is new | 18:50 | ||
| I think that t/spec/S17-supply/syntax.t was the one that sometimes hung | |||
| it now hangs like this: paste.scsys.co.uk/528615 | 18:51 | ||
| t/spec/S17-supply/wait.t now hangs in the same way as the other two: paste.scsys.co.uk/528616 | 18:52 | ||
| and t/spec/S17-supply/act.t is doing something strange with a single thread and a lot of sleeping | 18:53 | ||
| and slowly mmap'ing in more memory, but I can't work out why from strace | 18:55 | ||
| paste.scsys.co.uk/528618 | 18:56 | ||
| oooh, many tests failed | 18:57 | ||
| all in t/spec/S17-supply/ I think | 18:58 | ||
| ASAN makes no comment | |||
| let's try a complete clean build again... | 19:03 | ||
| geekosaur | it's entirely possible that fixing this uncovered other issues | 19:04 | |
| nwc10 | that was roughly my assumption | ||
| but I'm a bit surprised that both I see it and jnthn didn't, and that I see so much but ASAN remains silent | 19:05 | ||
| repeatable. | 19:39 | ||
| jnthn | What on earth... | 19:46 | |
| jnthn had clean spectest :/ | |||
| jnthn does a clean build of what's in nom | 19:47 | ||
| Moar master / NQP 255d2e9d1f1 / Rakudo 948aee0f405 just gave me a clean spectest on Linux in my VM, TEST_JOBS = 12, 4 cores available to the VM | 19:55 | ||
| nwc10 | this is 24 cores | 19:57 | |
| jnthn | Building with NQP and Rakudo at HEAD now | ||
| Though NQP had no changes execpt to the js backend | |||
| Feels like a big discrepancy to just be "bad luck" | 19:58 | ||
| Or "good luck" in my case | |||
| Not that I'm especially lucky, in that I see to be the only person around here who can debug difficult concurrency problems. :P | |||
| nwc10 | a non-ASAN built then run under valgrind doesn't give any insight | 19:59 | |
| (same failures, still no barfage) | 20:00 | ||
| jnthn | Guess I can try it on Windows too | 20:01 | |
| ooh | |||
| I just got an S17-supply failure | |||
| Two | |||
| nwc10 | \o/ and /o\ | 20:02 | |
| jnthn | 3 | ||
| More | |||
| So, interesting. Same MoarVM version in both runs. Same NQP code in both runs. | 20:03 | ||
| That ASAN doesn't barf is at least mildly suggestive "not MoarVM" too | 20:04 | ||
| nwc10 | yes, agree. Looks like the bad logic might be further up the stack | 20:05 | |
| jnthn | It doesn't need load to fail | 20:06 | |
| elems.t is totally repeatable for example | |||
| Slightly complicating this is that I think when I put my Supply patch in I did a pull --rebase | |||
| But it was clean even with that, it turns out. Looks like a commit after my supply changes in nom bust it | 20:16 | ||
| nwc10 | ah, OK, oops | ||
| so I'm mentioning this in the wrong channel | |||
| jnthn | Yeah, though here was a good guess. | ||
| I mean, given what I was working on today, it was overwhelmingly likely just from the list of failed tests that it was going to be something I'd done. :) | 20:17 | ||
| On the other hand, everything I've worked on today was about things that were hard to reproduce :) | 20:18 | ||
| So when the failures were so easily reproducable I had a hunch it was going to be something else. :) | 20:19 | ||