EXC_BAD_ACCESS crash when decoding data from Firestore

[fanwgwg]

Description

Sometimes when decoding data from Firestore, I'd encounter this EXC_BAD_ACCESS crash.

Thread 1 Queue : com.apple.main-thread (serial)
#0	0x000000010724421c in -[FSTUserDataWriter convertedValue:] ()
#1	0x0000000107244344 in -[FSTUserDataWriter convertedObject:] ()
#2	0x0000000107244288 in -[FSTUserDataWriter convertedValue:] ()
#3	0x000000010720a08c in -[FIRDocumentSnapshot dataWithServerTimestampBehavior:] ()
#4	0x000000010720a544 in -[FIRQueryDocumentSnapshot dataWithServerTimestampBehavior:] ()
#5	0x000000010720a4a0 in -[FIRQueryDocumentSnapshot data] ()

Reproducing the issue

The issue occurs sporadically during data decoding from Firestore. Notably, the data contains a blob/Data field that can occasionally be empty, though not nil. This blob field stores protobuf data. Typically, data assignment to firestoreModel.data is performed as protoBufMessage.serializedData(). When all values in the protobuf match their default, the serialized data is Data() with 0 bytes.

Furthermore, crashes seem to manifest only when decoding documents with hasPendingWrites = true within snapshot listeners, indicating local writes. However, once a document has been successfully written to the server, subsequent decoding operations on the same document succeed consistently, whether from snapshot listeners or direct queries.

I'm also seeing similar crash reports at

• Firebase Query Crash, EXC_BAD_ACCESS (KERN_INVALID_ADDRESS) on App Startup (iOS) #11978
• Crashed: com.apple.main-thread EXC_BAD_ACCESS KERN_INVALID_ADDRESS -[FIRQueryDocumentSnapshot data] + 44 #10514
• 🐛 [cloud_firestore] Crash Subscribing to Data at Startup flutterfire#11528
• Firestore Crash with Empty Blob field #11773

e.g.,

struct FirestoreModel: Codable {
  @DocumentID var id: String?
  var data: Data
}

Firebase SDK Version

10.23.0

Xcode Version

15.2

Installation Method

Swift Package Manager

Firebase Product(s)

Firestore

Targeted Platforms

iOS

Relevant Log Output

No response

If using Swift Package Manager, the project's Package.resolved

Expand Package.resolved snippet

Replace this line with the contents of your Package.resolved.

If using CocoaPods, the project's Podfile.lock

Expand Podfile.lock snippet

Replace this line with the contents of your Podfile.lock!

[google-oss-bot]

I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.

[fanwgwg]

here's the data's representation on firestore, which is empty as expected.

Querying the same document on android will result in no issues though. My app has both ios and android.

After some experiments, I can confirm that as long as the Data contains some bytes, this crash will not happen. Interestingly it seems like these "some bytes" cannot be empty bytes like Data(count: 1), which still causes the crash

[tom-andersen]

Thank you for the report. I will look into this as soon as possible.

[fanwgwg]

Thanks @tom-andersen. May I know if there is any update on this? Our current workaround is to add a check everywhere we use Data to make sure it's not empty when written to Firestore, however, this is lots of unnecessary code to maintain and also error-prone for us, so I'd greatly appreciate it if this issue could be looked into as soon as possible.

Thank you in advance.

[tom-andersen]

Hi @fanwgwg!

I took the time to repro the bug. With your good observations and explanation this was quite easy. Thank you!

I am working on a fix, but I also want to be sure there aren't any unforeseen consequences.

[tom-andersen]

Fix will be part of next release.

[fanwgwg]

@tom-andersen Thank you for the fix!