The Mac got slower, and quitting the app didn't fix it

Vishwas Prakash — Tue, 01 Sep 2026 14:48:35 +0000

This is the worst bug I have written. Not because the app broke — it worked fine throughout — but because it degraded the machine it ran on, permanently, and left the damage behind after quitting. Someone could have uninstalled the app and still been slow, with nothing to connect the two.

ExtendPilot puts a real second desktop on an iPad: not a mirror, but a display macOS treats as hardware, arrangeable in System Settings, with windows that move onto it. There is no public API for that, so it sits on a private one. This is the story of what the private one does when you hold it wrong.

What it looked like

After a day of development the Mac had a load average around 6 and felt unusable. Three ColorSync daemons were burning about 115% CPU between them — over a full core — and had been for 47 minutes at the point of measurement.

$ top -l 2 -o cpu
colorsyncd                 46.5%
colorsync.displayservices  35.6%
colorsync.useragent        33.2%

They were not logging anything. A full log show came back empty, so nothing pointed at them at all. Two of the three run as root; sampling the one running as the user gave the hot stack immediately.

$ sample 96211 3
  21  ColorSyncXPCDeviceRegistryCopyAnyUserInfo
  20  ColorSyncDeviceRegistryCopyInfo
  11  ColorSyncIterateDeviceProfiles
  10  ColorSyncProfileCreateWithURLAndOptions
   7  ColorSyncCreateCFDataFromURL
  40  __CFBinaryPlistCreateObjectFiltered

Iterating the display device registry and re-reading profiles off disk, in a loop. So the question became how big the registry had got.

$ ls -1 /Library/ColorSync/Profiles/Displays/ | wc -l
97
$ ls -1 /Library/ColorSync/Profiles/Displays/ | grep -c LocalScreenShare
72
$ find /Library/ColorSync/Profiles/Displays/ -mtime -1 | wc -l
77

Seventy-two of ninety-seven profiles were ours, and seventy-seven of them had been created that day. Every one was an ICC profile that colorsyncd had written for a monitor it had never seen before. We had been handing it a brand new monitor every few minutes, and it had been dutifully profiling each one and keeping the result forever.

The line not falling at the quit marker is the part that made this hard to find. Every instinct says a leak ends when the process does, so the machine stayed slow long after the obvious suspect had exited.

The cause is one line

A virtual display is created from a descriptor. Three of its fields build the display's identity:

static uint32_t nextIndex = 0;
descriptor.productID = 0x4C53;
descriptor.vendorID  = 0x3456;
descriptor.serialNum = ((uint32_t)getpid() << 8) | (nextIndex++ & 0xFF);

The vendorID / productID / serialNum triple is a display's identity to macOS. Mixing in getpid() meant that identity changed on every launch. macOS concluded, correctly, that it had never seen this monitor before, and colorsyncd did exactly what it is supposed to do for a new monitor: profile it, and keep the profile. Around 36 launches, two desktops each, is 72 profiles.

The bitter part is that this line was itself a fix. An earlier version gave every display the same serial number, and macOS then treated two simultaneous desktops as one monitor — each inheriting the other's saved arrangement and coming up at the wrong size. Adding the pid made them distinct, and it worked. It also made them distinct across time, which nobody had asked for and nobody noticed.

An identity that had to be stable was derived from something ephemeral. The requirement was "distinct from its siblings". The implementation delivered "distinct from everything, forever".

The first fix was not enough

Replacing the pid with a hash of the display's own size and slot fixes the across-launch case, because both of those are properties of the desktop rather than of the process that made it:

descriptor.serialNum = ((width & 0x1FFF) << 19) | ((height & 0x1FFF) << 6) | slot;

But slot still came from nextIndex++, a counter that only ever goes up. Within a single session, removing a desktop and adding another advanced it — and applying a saved preset does exactly that, removing every desktop and recreating them. Applying a preset three times minted six identities without the app ever restarting.

The file timestamps said so plainly: profiles written at 00:45, 00:58, 01:04, 01:06 and 01:13. Minutes apart, inside one session. The fix is that the slot is now passed in by the caller, which already knows each desktop's position in its own list — it does not need a counter to tell it.

A counter that only increments is the subtle version of this bug. It looks stable because it is deterministic. A counter is a clock in disguise.

Neither was the second

Creating a display can fail if another process already holds that identity, so there is a fallback path. In the same commit that fixed the two problems above, the fallback read:

if (!display) {
    descriptor.serialNum = ((uint32_t)getpid() << 8) | (slot & 0xFF);   // ← pid again
    …
}

The same mistake, a third time, written by someone who had spent the previous hour understanding why it was a mistake. It fires rarely, but when it fires it is unbounded. It is now four bounded alternates, so a given size costs at most four profiles ever, rather than one per launch:

for (uint32_t attempt = 0; attempt < 4 && !display; attempt++) {
    descriptor.serialNum = ((width & 0x1FFF) << 19) | ((height & 0x1FFF) << 6)
                         | ((slot & 0x0F) | (attempt << 4));
    display = [[displayClass alloc] initWithDescriptor:descriptor];
}

Three passes to get one line right. Worth remembering the next time a fix feels obvious.

A postmortem without a check is just a story

The regression check creates the two desktops, releases them, counts the profiles on disk, creates the same two again, releases them, and counts again. If a repeat run ever mints a new identity, the number moves and the check fails.

display profiles on disk: 27 before the repeat, 27 after

Writing that check turned up a second bug worth recording, because it is a good example of a test being right for the wrong reason. The first version passed the displays back through out-parameters. Under ARC those are __autoreleasing, so the pool held the displays alive well past the point where the test released them, and the check failed with "a virtual display outlived its owner". The check was correct. The check's own helper was the thing leaking. Each round now gets its own @autoreleasepool, and there is a comment next to it explaining why no helper exists.

The code fix stops new profiles. It cannot remove the seventy-two already written, which are root-owned and have to be deleted by hand. That asymmetry is the part I would most like other people to take away from this: the damage outlived the process, the fix does not reach backwards, and no amount of care after the fact recovers it.

What to look for in your own code

Identity derived from something ephemeral. Anything the OS persists or registers under a key you generate must have that key derived only from what genuinely distinguishes the thing. Audit any use of getpid(), a timestamp, a UUID, a random number or a monotonic counter that feeds a serial number, a filename, a bundle id, a service name, a Keychain account, a Bonjour name or a cache key.

The question that finds it: if this runs a thousand times, how many distinct values does the OS end up storing? If the answer is a thousand, this is your bug.

Resources the OS keeps after you exit. Virtual displays go away when released; the profiles do not. Before using an API that registers something system-wide, ask what survives the process, and whether anything ever cleans it up. In our case nothing did, and still does not — the fix is that we stop creating them, not that we tidy up.

Silent hot loops. colorsyncd logged nothing at all while spinning. The only thing that found it was sampling the hot stack. When something is eating CPU and the logs are quiet, sample it rather than reasoning about it. And note that ps reports %CPU as a lifetime average rather than a current reading — a 47-minute-old process showing 73% in top -l 2 has been there the whole time, which is a far stronger signal than a spike.

ExtendPilot shares a Mac's screen with the iPhones and iPads already in the room — as a mirror, or as a second desktop macOS treats as real hardware. Peer to peer over your own Wi-Fi, no account, no server in a session, so it works with the router unplugged. Built for the meeting room whose HDMI cable never works, and for the iPad on the desk doing nothing. The Mac app is a free notarised download, or brew install vishwas3000/tap/extendpilot; the iPhone and iPad app is with App Review. Every performance claim about it traces to a session like the one above, written down with the number that was true before and the number that was true after. So do the mistakes; this is one of them.