Thank you Léonie,
My libraries are non-system photo libraries and local stored in de pictures folder. I still have 300 gb storage. Before the update of last monday there was no problem. There are no apps hanging or hogging the memory. Quiting apps and safe mode doesn't work either:
Title:
Photos permanently hangs / crashes when editing Nikon NEF RAW files on macOS 15.8 (24H23)
Summary:
Since updating to macOS 15.8 (24H23), the Photos app either permanently freezes or crashes when opening a Nikon NEF RAW file (Nikon Z6III) in edit mode. This did not occur prior to this update. Two distinct failure modes have been captured, both pointing to instability in the same underlying render pipeline.
System information:
- Model: iMac19,1 (2019, Intel)
- GPU: AMD Radeon Pro 570X (discrete)
- OS: macOS 15.8, Build 24H23
- Photos version: 10.0 (770.0.177)
- Camera: Nikon Z6III (.NEF files)
Steps to reproduce:
- Open Photos
- Select a RAW photo (.NEF, Nikon Z6III)
- Click "Edit"
- In normal mode: a loading indicator appears in the bottom-right of the image and never disappears; the UI freezes completely and stops responding to input
- In Safe Mode: instead of freezing, the app crashes outright (see attached crash log)
Ruled out during troubleshooting:
- Not related to iCloud Photo Library sync (tested with local, non-system libraries)
- Not related to Photos extensions (disabled — issue persists)
- Not related to network/firewall software
- No elevated CPU or memory usage observed during the freeze (this is a blocking wait state, not a compute-bound issue)
- Reproducible across multiple, separate local photo libraries
- Worked correctly prior to updating to 15.8
Failure mode 1 — Freeze in normal mode (process sample attached):
A process sample taken during the freeze shows the main thread blocked in a synchronous dispatch call:
-[PAItemController isEditing] → dispatch_sync
waiting on the NUCGImageSourceNode background thread, which is itself blocked on a mutex inside Apple's RawCamera decoder plugin:
IIOReader_RawCamera::callUpdateSourceProperties
→ CGImageSourceAddProperty
→ _pthread_mutex_firstfit_lock_wait
→ __psynch_mutexwait
This indicates a deadlock inside the RawCamera plugin (ImageIO framework) while reading/adding metadata properties from the NEF file — no CPU usage is observed because the thread is blocked waiting on a lock that never releases.
Failure mode 2 — Crash in Safe Mode (crash log attached):
In Safe Mode (reduced GPU acceleration / disabled kernel extensions), the same operation instead triggers a hard crash via an internal assertion in the NeutrinoCore render pipeline:
-[NURenderer renderImage:rect:toDestination:atPoint:error:]
→ _NUAssertFailHandler
→ -[NUAssertionPolicyAbort notifyAssertion:]
→ abort() (SIGABRT)
Crashed thread: NUJobQueue.Interactive_Render.run. This is a deliberate internal safety abort — Photos' own code detects an invalid/inconsistent state in the render pipeline and intentionally terminates rather than continuing with corrupted state.
Analysis:
Both failure modes point to instability in the same rendering path when processing this Nikon NEF RAW data — likely triggered by processing of maker-note/EXIF metadata during RAW decode combined with GPU-accelerated rendering (NeutrinoCore/Core Image). Under normal GPU-accelerated rendering, this manifests as a deadlock; under Safe Mode's reduced rendering path, it manifests as an assertion crash instead. The discrete AMD GPU (Radeon Pro 570X) may be a contributing factor, as this class of render-pipeline issue is more commonly seen on Intel Macs with discrete GPUs.