google-oss-bot
commented
4 years ago I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.
Open elefantel opened 4 years ago
google-oss-bot
commented
4 years ago I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.
morganchen12
commented
4 years ago Analytics uses sqlite in fullmutex mode, so concurrent accesses should not cause crashes. Analytics may normally access sqlite from multiple threads without an additional SDK added.
Can you check if mParticle_Apple_SDK is shipping its own version of sqlite or if it's opening the sqlite database in a non-threadsafe mode?
elefantel
commented
4 years ago Hi @morganchen12
See - (void)updateSession:(MPSession *)session here perhaps you can advise?
https://github.com/mParticle/mparticle-apple-sdk/blob/5bea9cb078e198803178a9be0cdded131e8f9a09/mParticle-Apple-SDK/Persistence/MPPersistenceController.mm
morganchen12
commented
4 years ago Based on this line it looks like mParticle expects sqlite to be compiled in multi-thread mode. Analytics expects to be able to open a database in serialized mode. Can you try removing the mParticle SDK and seeing if it causes the Analytics crashes to go away?
elefantel
commented
4 years ago Yeah that seems to be the case as they are expecting sqlite3_threadsafe() to return 2 instead of 1. I have reached out to mParticle for feedback. Thanks!
elefantel
commented
4 years ago @morganchen12 Feedback from mParticle:
1) No, we are not shipping our own version of sqlite
2) No, we are not opening the database in a non-threadsafe mode,
we use fullmutex same as firebase does
3) We support sqlite being compiled in either multi-thread or serialized mode
That line in the unit test is only there to help us monitor the platform SQLite settings
so that if Apple makes changes in a new Xcode version, our unit tests will break
and we can verify whether there are any changes to make on our endThat means we have reached a deadlock :(
morganchen12
commented
4 years ago Thanks for updating @elefantel, it seems I have led us down the wrong debugging path.
Can you share your version of Analytics? The FIRASQLiteStore class has been renamed and should not exist in your app if you're using the latest version of Analytics.
elefantel
commented
4 years ago Thanks for the feedback @morganchen12 . Yes it has changed to APMSqliteStore I believe, we now receive crashes from:
[APMSqliteStore executeSQLStatement:error:][APMSqliteStore endTransaction][APMSqliteStore openAndValidateDatabase:]
And a few more.Not sure the latest version has changed much as we still get the crashes from the same functions. The attached stack trace above shows an APMSqliteStore crash.
Our Podfile.lock looks like this:
- FBSDKCoreKit (5.7.0):
- FBSDKCoreKit/Basics (= 5.7.0)
- FBSDKCoreKit/Core (= 5.7.0)
- FBSDKCoreKit/Basics (5.7.0)
- FBSDKCoreKit/Core (5.7.0):
- FBSDKCoreKit/Basics
- FBSDKLoginKit (5.7.0):
- FBSDKLoginKit/Login (= 5.7.0)
- FBSDKLoginKit/Login (5.7.0):
- FBSDKCoreKit (~> 5.0)
- Firebase/Analytics (6.23.0):
- Firebase/Core
- Firebase/Core (6.23.0):
- Firebase/CoreOnly
- FirebaseAnalytics (= 6.4.2)
- Firebase/CoreOnly (6.23.0):
- FirebaseCore (= 6.6.7)
- Firebase/Crashlytics (6.23.0):
- Firebase/CoreOnly
- FirebaseCrashlytics (~> 4.0.0)
- FirebaseAnalytics (6.4.2):
- FirebaseCore (~> 6.6)
- FirebaseInstallations (~> 1.2)
- GoogleAppMeasurement (= 6.4.2)
- GoogleUtilities/AppDelegateSwizzler (~> 6.0)
- GoogleUtilities/MethodSwizzler (~> 6.0)
- GoogleUtilities/Network (~> 6.0)
- "GoogleUtilities/NSData+zlib (~> 6.0)"
- nanopb (= 0.3.9011)
- FirebaseAnalyticsInterop (1.5.0)
- FirebaseCore (6.6.7):
- FirebaseCoreDiagnostics (~> 1.2)
- FirebaseCoreDiagnosticsInterop (~> 1.2)
- GoogleUtilities/Environment (~> 6.5)
- GoogleUtilities/Logger (~> 6.5)
- FirebaseCoreDiagnostics (1.2.4):
- FirebaseCoreDiagnosticsInterop (~> 1.2)
- GoogleDataTransportCCTSupport (~> 3.0)
- GoogleUtilities/Environment (~> 6.5)
- GoogleUtilities/Logger (~> 6.5)
- nanopb (~> 0.3.901)
- FirebaseCoreDiagnosticsInterop (1.2.0)
- FirebaseCrashlytics (4.0.0):
- FirebaseAnalyticsInterop (~> 1.2)
- FirebaseCore (~> 6.6)
- FirebaseInstallations (~> 1.1)
- GoogleDataTransport (~> 6.0)
- GoogleDataTransportCCTSupport (~> 3.0)
- nanopb (~> 0.3.901)
- PromisesObjC (~> 1.2)
- FirebaseInstallations (1.2.0):
- FirebaseCore (~> 6.6)
- GoogleUtilities/Environment (~> 6.6)
- GoogleUtilities/UserDefaults (~> 6.6)
- PromisesObjC (~> 1.2)
- GoogleAppMeasurement (6.4.2):
- GoogleUtilities/AppDelegateSwizzler (~> 6.0)
- GoogleUtilities/MethodSwizzler (~> 6.0)
- GoogleUtilities/Network (~> 6.0)
- "GoogleUtilities/NSData+zlib (~> 6.0)"
- nanopb (= 0.3.9011)
- GoogleDataTransport (6.0.0)
- GoogleDataTransportCCTSupport (3.0.0):
- GoogleDataTransport (~> 6.0)
- nanopb (~> 0.3.901)
- GoogleSignIn (5.0.2):
- AppAuth (~> 1.2)
- GTMAppAuth (~> 1.0)
- GTMSessionFetcher/Core (~> 1.1)
- GoogleUtilities/AppDelegateSwizzler (6.6.0):
- GoogleUtilities/Environment
- GoogleUtilities/Logger
- GoogleUtilities/Network
- GoogleUtilities/Environment (6.6.0):
- PromisesObjC (~> 1.2)
- GoogleUtilities/Logger (6.6.0):
- GoogleUtilities/Environment
- GoogleUtilities/MethodSwizzler (6.6.0):
- GoogleUtilities/Logger
- GoogleUtilities/Network (6.6.0):
- GoogleUtilities/Logger
- "GoogleUtilities/NSData+zlib"
- GoogleUtilities/Reachability
- "GoogleUtilities/NSData+zlib (6.6.0)"
- GoogleUtilities/Reachability (6.6.0):
- GoogleUtilities/Logger
- GoogleUtilities/UserDefaults (6.6.0):
- GoogleUtilities/Logger
- GTMAppAuth (1.0.0):
- AppAuth/Core (~> 1.0)
- GTMSessionFetcher (~> 1.1)
- GTMSessionFetcher (1.3.1):
- GTMSessionFetcher/Full (= 1.3.1)
- GTMSessionFetcher/Core (1.3.1)
- GTMSessionFetcher/Full (1.3.1):
- GTMSessionFetcher/Core (= 1.3.1)
- Leanplum-iOS-SDK (2.6.4)
- nanopb (0.3.9011):
- nanopb/decode (= 0.3.9011)
- nanopb/encode (= 0.3.9011)
- nanopb/decode (0.3.9011)
- nanopb/encode (0.3.9011)I'll keep this open in case we see more instances of this crash. For the time being, we don't have a clear path towards fixing the bug without a repro or a greater understanding of what causes the bug.
elefantel
commented
4 years ago Thanks! Hopefully we can resolve this. It does look like others have been getting it over the years from back in 2018, like this one here that wasn't resolved https://github.com/firebase/firebase-ios-sdk/issues/1966
I will update as well when we find a solution. Thanks again!
Step 0: Are you in the right place?
firebasetag.[REQUIRED] Step 1: Describe your environment
CocoaPods[REQUIRED] Step 2: Describe the problem
Steps to reproduce:
We are getting a lot of crashes from
[FIRASqliteStore executeSQLStatement:error:]. It seems to be a threading issue but it is difficult to reproduce, but two things are the common denominator in all the crashes:1)
sqlite32)_os_unfair_lock_unowned_abortWe are not working with sqlite3 directly in our codebase but use Core Data for our persistence. What we have noticed though is that
FIRASqliteStorecrashes tend to include (not always)mParticle_Apple_SDKand vice versa and always have bothsqlite3and _os_unfair_lock_unowned_abort entries in the logs. We are wondering if it it may be because of a race condition insqlite3between the two SDKs we have in our app?We have been having the crashes since early last year, so not much to do with the latest versions per se.
Relevant Code: