Yesterday, while preparing a new game prototype, I encountered what is perhaps the dumbest persistent kernel panic I’ve ever encountered. A benign everyday action triggered a catastrophic kernel panic loop in the current version of macOS Tahoe 26.4.1. I want to talk about it.

Last night I was settling in to set up a new project. I was unwinding with a short YouTube video before getting started when my Mac suddenly panicked and rebooted. Huh, weird, but whatever. Logged back in, started loading up Unity, and after a minute, the system panicked again.

Oh dear.

After booting up again, I decided to perform a clean restart. Maybe I had some weird app doing something wrong. No dice. Time to load up Activity Monitor to see what’s happening before it crashes again.

Wait, why is HydraRenderingService quickly spiking to 16+ GB of RAM? What even is that?

Some Googling and a panic log fished out of recovery mode told me a few things. HydraRenderingService is an Apple XPC service used to render 3D USD content for other parts of the system. And somehow this was causing the entire system to fall over.

The actual panic log was only mildly enlightening.

panic(cpu 2 caller 0xfffffe004711ceec): "skr.ubft.fsw_en0_CategoriesService.831": skr 0x0xfffffe1d10c17e00 sg 0x0xfffffe1d10cd2008 (idx 1) unable to satisfy mandatory allocation

The kernel is failing to allocate memory. Okay, but… what’s even calling this?

Activity Monitor said the parent was launchd, apparently? This means macOS itself is spawning this on demand, not anything that I’ve launched myself. So what was actually asking for this? Among the relevant handles was /usr/lib/usd/usd/hdSt/resources/shaders/mesh.glslfx, which told me shaders for 3D mesh rendering were being compiled. Sure, that follows, given the Hydra service. But I wasn’t running any 3D apps. That doesn’t follow.

It crashes again, and I contemplate the problem for a while. This has eaten about two hours of my evening. But wait a minute, hdSt is HdStorm, and that is used for thumbnail generation, isn’t it? Thumbnails for Finder, Spotlight, QuickLook, things like that. It would be used for generating thumbnails of previewable 3D asset files-

Oh. No. No way it’s this dumb. Absolutely no way.

I had downloaded a copy of the famous Kenney game assets all-in-one bundle a few days ago for use in the game project I was planning to work on. It had been on my desktop, and I had unzipped the archive a few hours before the panics started. Suddenly it all came together.

Spotlight had gotten around to indexing the extracted files. The Kenney assets include tens of thousands of individual files, many of which are 3D meshes. They’re fairly small assets. The AIO bundle, when extracted, isn’t even a single GB, so I didn’t think much of it. As part of this Spotlight indexing process, it seemed it decided to generate thumbnails for all the 3D files in the background. By loading them into system memory and rendering them. All at once. Unbounded with no apparent concurrency limits in place. Thus triggering an OOM panic in the kernel, rebooting, and starting over again.

The solution was, of course, simple. Delete the 80,000 files from the system before macOS panics, and then force a full system re-index. Lo and behold, the crash vanished, and I had full use of my computer again.

I’d like to note that my MacBook Pro is an M2 Max with 64GB of system RAM. And yet that wasn’t enough to prevent macOS from crashing when a first-party system service tried to render thousands of small 3D assets concurrently in the background, with no apparent memory caps in place. This is one of the most ridiculous bugs I’ve seen in a long time, and I feel like this needs to be addressed. A user’s computer shouldn’t be put into a panic loop because they happened to have a bunch of benign files on their SSD.

Well, it’s really late at night now and I don’t have time to work on anything at this point. Perhaps Apple could consider improving their internal stress testing on macOS.