OK, first of all, thank you for the report. The issue is indeed there, and in my opinion it's a significant problem.
Secondly, ♥👍 for trying to bisect it manually. Nowadays I only do it with a bot unless I have to trisect rakudo+nqp+moar. However, the result of bisection is wrong (as far as I can see), and my guess is that on some steps you used “git bisect bad” when you should have used “git bisect skip” (when bisecting automatically you should use exit code 125 in these situations). It just happens that on some commits you can't really build rakudo (e.g. some work was split into several commits so some of the intermediate versions are unbuildable). We should try to avoid these situations, but it happens. On these commits you don't really know if the bug is there or not because there is simply no way to test. Similar bug (but not the same one) was bisected with a bot, and you can take a look at the result: https://gist.github.com/Whateverable/0f0acba0af518988ddddeb207fd52fae (the commit you are talking about is listed there as well). In other words, the problem appeared in better-sched branch, and not exactly in the commit you mentioned. Now, talking about the code you've used, it looks a bit weird to me. It seems that you're doing async access to %c which should probably be protected with a lock. In any case, I was able to reproduce the issue without most of that code, by using just qqx. See GH #1202 ( https://github.com/rakudo/rakudo/issues/1202 ). As far as I can see (judging by GH #1202), the issue is much *easier* to reproduce now with better-sched, but the bug was there for a long time. So for the 2017.10 release: SNAFU. On 2017-10-16 18:27:57, jdv79 wrote: > No, sorry. I meant that I only tested for a couple minutes at each > commit. > Commits before the one bisect found never manifested the issue. > > On 2017.10.16 10:52 am, jn...@jnthn.net via RT wrote: > > On Fri, 13 Oct 2017 10:13:36 -0700, jdv79 wrote: > >> The symptom is that sometimes (90%+ on my box and ungolfed) the > >> program > >> seems to stall out on the qqx line. The last thing that is printed > >> is > >> "before". But on earlier commits (that actually build) no such > >> stallage > >> happened for a couple minutes run time. > >> > > So if I follow correctly, the changes in the commit mentioned make an > > existing problem manifest sooner, rather than introduce the problem?
