kahest
commented
9 months ago @kvdesa thank you for reporting this, we'll look into it!
Internal references: release 8.9.4, release 8.20.0
Open kvdesa opened 9 months ago
kahest
commented
9 months ago @kvdesa thank you for reporting this, we'll look into it!
Internal references: release 8.9.4, release 8.20.0
kvdesa
commented
9 months ago I don't know if it's related, but I just did a bit more digging and found out that the calls of our app, Mimo, in thread 4:
13 Mimo 0x20152fd48 Session.updateStatesForTask (Session.swift:1124)
14 Mimo 0x20152fa00 Session.didCreateURLRequest (Session.swift:1106)
15 Mimo 0x20153d9ec Session.performSetupOperationsthat happen right before some Sentry related calls in the same thread:
3 Mimo 0x2013a66b0 -[SentrySpan setDataValue:forKey:] (SentrySpan.m:129)
4 Mimo 0x20138cb28 __45-[SentryNetworkTracker urlSessionTaskResume:]_block_invoke (SentryNetworkTracker.m:183)
5 Mimo 0x20139f2fc -[SentryScope useSpan:] (SentryScope.m:148)
6 Mimo 0x20138c61c -[SentryNetworkTracker urlSessionTaskResume:] (SentryNetworkTracker.m:173)
7 Mimo 0x20138ed74 __57+[SentryNetworkTrackingIntegration swizzleURLSessionTask]_block_invoke_2 (SentryNetworkTrackingIntegration.m:65)are related to another dependency we have, RxAlamofire, which happened to be updated to the latest version together with Sentry, don't know if you had anything similar in the past.
We decided to revert both these changes and see if this fixes the issue.
kahest
commented
9 months ago @kvdesa thank you for the additional details, that's really helpful! Can you tell us the version(s) of RxAlamofire you use?
What you observe is our network tracking kicking in. In case reverting the versions doesn't work you can instead temporarily deactivate network tracking as shown in the docs linked above, while we work an a solution.
kvdesa
commented
9 months ago @kvdesa thank you for the additional details, that's really helpful! Can you tell us the version(s) of RxAlamofire you use?
The previous version of RxAlamofire, that we reverted back to, is 6.0.0 and the new version, that we upgraded together with Sentry's 8.20.0, is 6.1.2.
Platform
iOS
Environment
Production
Installed
Swift Package Manager
Version
8.20.0
Did it work on previous versions?
8.9.4
Steps to Reproduce
After updating from
8.9.4to8.20.0, we saw a significant increase in this crash. It already occurred when using the previous version, but at a smaller rate. Now, we are considering reverting to the old version if this persists. After a quick search, I found this issue that was fixed in8.15.2, I don't know if it's related.Crash Report
OS Version: iOS 17.2.1 (21C66) Report Version: 104 Exception Type: EXC_BREAKPOINT (SIGTRAP) Crashed Thread: 0 Application Specific Information: Exception 6, Code 1, Subcode 8944013932 Thread 0 Crashed: 0 libsystem_platform.dylib 0x406eb826c _os_unfair_lock_corruption_abort 1 libsystem_platform.dylib 0x406eb5354 _os_unfair_lock_lock_slow 2 libobjc.A.dylib 0x3236744b0 objc_sync_enter 3 Mimo 0x2013a66b0 -[SentrySpan setDataValue:forKey:] (SentrySpan.m:129) 4 Mimo 0x2013a6e60 -[SentrySpan finishWithStatus:] (SentrySpan.m:217) 5 Mimo 0x2013afdbc -[SentryTracer deadlineTimerFired] (SentryTracer.m:277) 6 Mimo 0x2013afb28 __34-[SentryTracer startDeadlineTimer]_block_invoke_2 (SentryTracer.m:259) 7 Foundation 0x33163bd88 __NSFireTimer 8 CoreFoundation 0x33306d3e8 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ 9 CoreFoundation 0x33306d090 __CFRunLoopDoTimer 10 CoreFoundation 0x332ff6c80 __CFRunLoopDoTimers 11 CoreFoundation 0x332ff3c98 __CFRunLoopRun 12 CoreFoundation 0x332ff3474 CFRunLoopRunSpecific 13 GraphicsServices 0x3b9b254f4 GSEventRunModal 14 UIKitCore 0x337642628 -[UIApplication _run] 15 UIKitCore 0x337641c64 UIApplicationMain 16 Mimo 0x2009dcaf8 main (main.swift:16) 17Expected Result
Crash
Actual Result
No crash.
Are you willing to submit a PR?
No response