[oliverames]

What and why

Mario Kart World 1.8.0 on a physical iPhone ended about 85 s into a race with *** Terminating app due to uncaught exception 'com.apple.CoreHaptics', reason: '-[CHHapticEngine(CHHapticEngineInternal) checkEngineRunning:]: self.running' and [dm] CRASH sig=6, a few seconds after the log's oe focus state changed twice (2, then 1). It was not memory: the footprint was flat at about 3.7 GiB.

Core Haptics reports a player or parameter call on an engine that is not running by raising an NSException, not by returning an NSError. The engine stops on its own (audio interruption, focus change, helper exit) and its stopped handler is only queued onto the adapter's serial queue, so a pulse renewal or a level change can reach the engine first. Every error: path was already handled; this is not an error return.

apply: and the pulse renewal now run in @try; a caught exception is handled as a failed engine (stop, drop the engine, back off like a failed start, clear the queued output, [RED] haptics: ... on a stopped engine), so the next effect builds a new engine. Reference entry: A haptic engine that stops under a call raises; game note line in dm/games/0400C3F00006E000/README.md.

Checked

• Tests: t_haptics_apple gains a case that raises from a player's sendParameters: it passes with the change and ends in the same uncaught NSException without it (built and run on the Mac); dm/tools/tests/test_docs.py passes.
• Games run, with title ID and version: Mario Kart World (0400C3F00006E000) 1.8.0, built from WIP: Mario Kart World 1.8.0 on iOS - rendering, memory and presentation #1383's tree, on the phone: two later runs of the build with this change (about 80 s and about 5 minutes) ended without the crash; neither forced an engine stop.
• Devices and OS: iPhone 19,4 (2 Performance + 4 Efficiency cores), iOS 27.3; Apple-silicon Mac, macOS 27.3
• scripts/regress.py check --games: not run: the change only adds an exception handler around Core Haptics calls on the Mac and iOS front ends; nothing runs differently unless Core Haptics raises.
• Not checked: the guard itself has only been exercised by the unit test (no run forced an engine stop); no haptics were felt on a controller with the change.

Front ends

None: no front end has to act on this.

Docs

• The finding is in docs/reference/services.md and the game note; python3 dm/tools/docs_symptoms.py was run
• A chain tool changed: dmsh_chain.py --header was run and dm/gfx/nvn/dmsh_chain.h is part of the change. Not applicable: no chain tool changed.
• No game files, keys or data extracted from a game in the change or the attachments

[seedds]

Thanks — landed on main as 7238bfd, with you as co-author. The diagnosis, the raising test fake and the docs are yours.

Two changes on top:

• The recovery could raise again. stoppedEngine: called [self stop] inside the catch. On the plain-player route (Xbox controllers, one engine for both handles), stop sends zero to both players with sendParameters, which is the call that raises on a stopped engine, so the app still ended. The recovery now drops the engine and its players without calling them; nothing plays from an engine that isn't running.
• Every entry into a channel is guarded, not only apply: and the pulse renewal. The idle release, the stop queued by the engine's stopped/reset handler, focus loss, reconfiguration with its fallback/merge routes, and the delayed engine stop all call players on the same queue and could lose the same race. They now go through one guarded:work: helper. The [RED] line names the target and is rate-limited like report().

t_haptics_apple gained plain-player cases (a raise from a level change and from the idle release). Your version ends in an uncaught NSException on the first of them. The reference entry now says which call raised in your crash is unknown, since the log has no backtrace. It may also have been the adapter's own asynchronous stop on the focus loss racing the restart on the focus return; the guard covers either. A raise leaks what ARC held in the unwound frames (the host has no -fobjc-arc-exceptions), about 300 bytes a raise, which the code comment notes.

Still untested: a forced engine stop on a device. If you hit the crash again, a log with the new [RED] haptics: … on a stopped engine line would show which stage raised.