Fix locking mechanism to avoid iOS 26 crash with progressiveLoad concurrency - #3876

SDWebImage/Core/SDImageIOAnimatedCoder.m (1)

781-795: ⚠️ Potential issue | 🟠 Major

Lock the state transition, not just CGImageSourceUpdateData.

_imageData and _finished are still updated before this new critical section. That leaves a window where another thread can observe finished == YES while _imageSource still contains the previous bytes.

Suggested fix

-    if (_finished) {
-        return;
-    }
-    _imageData = data;
-    _finished = finished;
-
-    // Lock before updating the image source to prevent concurrent access from the frame fetch queue.
-    // CGImageSource is not thread-safe for simultaneous read+write.
-    SD_LOCK(_lock);
+    // Lock before mutating any incremental state so readers observe
+    // `_imageData`, `_finished`, and `_imageSource` atomically.
+    SD_LOCK(_lock);
+    if (_finished) {
+        SD_UNLOCK(_lock);
+        return;
+    }
+    _imageData = data;
+    _finished = finished;

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@SDWebImage/Core/SDImageIOAnimatedCoder.m` around lines 781 - 795, Move the
state mutation into the locked critical section: acquire SD_LOCK(_lock) before
updating _imageData and _finished, then call
CGImageSourceUpdateData(_imageSource, (__bridge CFDataRef)data, finished) while
still holding the lock, and finally release the lock; this ensures readers
cannot observe _finished == YES while _imageSource still has old data—use the
existing SD_LOCK/_lock and CGImageSourceUpdateData identifiers to locate and
reorder the statements accordingly.

SDWebImage/Core/SDImageIOAnimatedCoder.m (1)

787-822: ⚠️ Potential issue | 🟠 Major

Lock didReceiveMemoryWarning: around _imageSource mutations.

The progressive update path in -updateIncrementalData:finished: is now properly serialized under lock, but didReceiveMemoryWarning: still mutates the same shared _imageSource without _lock. A memory warning can interleave with the incremental update or frame fetch operations, creating a data race.

Suggested fix

 - (void)didReceiveMemoryWarning:(NSNotification *)notification
 {
+    if (_incremental) {
+        SD_LOCK(_lock);
+    }
     if (_imageSource) {
         for (size_t i = 0; i < _frameCount; i++) {
             CGImageSourceRemoveCacheAtIndex(_imageSource, i);
         }
     }
+    if (_incremental) {
+        SD_UNLOCK(_lock);
+    }
 }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@SDWebImage/Core/SDImageIOAnimatedCoder.m` around lines 787 - 822,
didReceiveMemoryWarning: currently mutates the shared _imageSource without
synchronization, causing races with updateIncrementalData:finished: and frame
fetches; wrap the entire body of -didReceiveMemoryWarning: (the code paths that
call CFRelease/CFBridgingRelease/CGImageSourceRelease or otherwise
modify/replace _imageSource and related state like
_imageData/_finished/_frameCount) with SD_LOCK(_lock) / SD_UNLOCK(_lock) so
mutations use the same lock used in updateIncrementalData:finished:, ensuring
accesses to _imageSource, _imageData, _finished and any calls that replace or
reset the image source are performed while holding _lock.