Repository navigation
PBGitWindowWiringTests fails when the machine is under load #643
Description
PBGitWindowWiringTests fails when the machine is busy. It passes
reliably on an idle one, which is why CI mostly stays green.
Reproduced on master (6d01d1ce), macOS 15.7.9, by saturating all
cores and running the full suite:
PBGitRevList.m:264: error: -[PBGitWindowWiringTests testTheWindowHandsOutTheControllersItBuilt]
: Error enumerating commits (NSInternalInconsistencyException)
A second run under load failed differently, in the same class:
PBGitWindowWiringTests.m:184: ((history.singleCommitSelected) is true) failed
PBGitWindowWiringTests.m:216: ("(null)") is not equal to ("refs/heads/branch_one")
Repro:
for i in $(seq 1 $(sysctl -n hw.ncpu)); do (while :; do :; done) & done
make unit-test ARCH=arm64
kill $(jobs -p)Two failures were filed here, and one has moved
This report describes two different failures that happen to land in the
same test class.
- The second traceback above is not a load problem at all. The
window opens on the stage view because an earlier GitX run persisted
that preference, so the history nib never loads and the outlets stay
nil. That is now PBGitWindowWiringTests fails when the app was left on the stage view #703, it reproduces deterministically on an idle
machine, and Fix CI-Tests - solve false-negative caused by poor setup (issue #703) #702 fixes it. - The first traceback is the genuine load and timing one, and is
what this issue is about from here on.PBGitRevList.m:264was
NSAssert(!enumError, ...)in production code, so an enumeration
error aborted rather than being handled; that was fixed in Fix GitX quitting when its history cannot be loaded #654.
The original text above is kept as filed, so the note about both
tracebacks racing the revision list is superseded by this section for
the second one.
What is left here
-cleanup cancels the walk and the graph queue, but cancelled
operations never run the completion blocks that call
-finishedGraphing, so nothing clears isUpdating. tearDown cleans
up and then waits on that flag, so no timeout saves it and the wait runs
its full 30 seconds. #686 makes -cleanup report the list as settled,
and makes the wait say whether the walk was still parsing or the graph
queue still had work, so the next failure names its own cause.
Still open beyond that: why the setUp wait expires in the first place.
PBGitHistoryGrapher.graphCommits: returns early without calling
-finishedGraphing when its commit list is empty or its thread was
cancelled, and -finishedGraphing only clears the flag when both the
walk and the queue are done, with nothing re-checking afterwards. Any of
those leaves the light on.
Activity
Stop the wiring tests racing the revision list (issue gitx#643)
goneng commentedon Sep 18, 2026
Reopening: #644 stopped the crash but not the condition underneath it. On a loaded arm64 runner the walk still does not finish, which now shows up as the 30 second wait timing out instead. The three CI runs and the details are in #669.
goneng commentedon Sep 19, 2026
Some numbers and a mechanism, from chasing today's master failure.
It has hit four times in the last 87 runs - 17 Sep master, 18 Sep #668,
19 Sep #683, 19 Sep master - always arm64, always on
((revisionList.isUpdating) is false), across three different test methods.That is a floor, not a rate: a run someone re-runs to green stops reporting the failure at all.
At least half of it is not load at all.
-cleanupcancels the walk and the graph queue,but cancelled operations never run the completion blocks that call
-finishedGraphing,so nothing clears
isUpdating.tearDowncleans up and then waits on that flag, so no timeout can save it -in today's master failure the two assertions are exactly 30 seconds apart, one per wait.
Locally each of these tests settles in under a second.
#686 makes
-cleanupreport the list as settled, and makes the wait saywhether the walk was still parsing or the graph queue still had work, so
the next failure names its own cause.
Still open after that: why the setUp wait expired in the first place.
PBGitHistoryGrapher.graphCommits:returns early without calling-finishedGraphingwhenits commit list is empty or its thread was cancelled, and
-finishedGraphingonlyclears the flag when both the walk and the queue are done, with nothing re-checking afterwards.
Any of those leaves the light on. Rather than guess, I would let the new message report it.
Separately, the
PBGitRevList.m:264NSAssert this issue flagged wasfixed in #654.
[-]PBGitWindowWiringTests fails when the machine is under load[/-][+]PBGitWindowWiringTests fails when the app was left on the stage view[/+]Fix the wiring tests inheriting whichever view ran last (issue #643)
[-]PBGitWindowWiringTests fails when the app was left on the stage view[/-][+]PBGitWindowWiringTests fails when the machine is under load[/+]goneng commentedon Sep 21, 2026
Closing this: everything filed here is either fixed or tracked
elsewhere, and nothing is left that belongs to this issue alone.
NSAssertabort, "Error enumerating commits"singleCommitSelectedand(null)The last row is the one worth flagging, because it was filed here as a
symptom of load and is not that at all. The window was opening on the
stage view, left there by a previous run through a persisted preference,
so the history nib never loaded and the outlets were nil. It reproduces
on an idle machine in one command and has nothing to do with how busy
the runner is. #703 has the detail.
What remains genuinely load-shaped is the 30 second wait, and #669
already describes it properly with the run IDs and durations. #686
carries the fix.