←back to thread

Apple Photos app corrupts images

(tenderlovemaking.com)
1140 points pattyj | 1 comments | 17 Sep 25 11:07 UTC | HN request time: 0.213s | source
Show context
deviation ◴[17 Sep 25 11:47 UTC] No.45274615[source]▶
It seems to be an import pipeline bug.

Photos does a lot of extra work on import (merging RAW+JPEG pairs, generating previews, database indexing, optional deletion), so my guess is a concurrency bug where a buffer gets reused or a file handle is closed before the copy finishes.

Rare, nondeterministic corruption fits the profile.

replies(7): >>45274840 #>>45275400 #>>45275556 #>>45275634 #>>45277188 #>>45278171 #>>45280431 #
tenderlove ◴[17 Sep 25 12:08 UTC] No.45274840[source]▶
This is also my guess. It's really a bummer, and I'd report it to Apple but since it's nondeterministic I have no idea how to provide repro steps.
replies(8): >>45275065 #>>45275163 #>>45276096 #>>45276185 #>>45276696 #>>45277780 #>>45279586 #>>45281857 #
groos ◴[17 Sep 25 18:31 UTC] No.45279586[source]▶
You don't need repro steps if Apple is serious about quality. Just the description of what's happening should give enough to a senior Apple engineer to intuit where this is possibly happening and create tests that will stress their software to repro this.
replies(2): >>45279624 #>>45288577 #
1. JKCalhoun ◴[18 Sep 25 12:03 UTC] No.45288577[source]▶
You're right. I too have been frustrated when spending the effort to file a bug only to have it "auto-returned" with "cannot repro, please attach example project" or somesuch.

As an engineer on a framework, I take pride in the code and want those trickier-to-repro bugs. And to your point, yeah, I can probably reconstruct in my mind a scenario, knowing my code, where it may be vulnerable.

Whoever screens bugs though is likely trying to 1) handle the huge backlog and 2) trying to spare the engineers bugs delivered with a shrug.

(I had my ass kicked by one bug in particular where I created a FileDescriptor on the main thread, did some things and then released the FileDescriptor on a background thread. Who knew the FileDescriptor code hung some important data it needed on some kind of thread-based storage that essentially required the caller to destroy the FileDescriptor on the same thread it was created on. Fix was to dispatch back to main when ready to release the FileDescriptor.)