https://kotlinlang.org logo
Join Slack
Powered by
Hi, any good advice on how to “normalize” iOS logs...
# ios
e
Hi, any good advice on how to “normalize” iOS logs when using sentry? As they are now, they seem to be unusable if kotlin error is thrown.
Our project is using sentry, if that makes any difference
f
Hello, can you try Kermit with a custom LogWriter using sentry?
a
You mean the stack trace in sentry doesn't have debug symbols?
e
@ade No, sentry does have dsyms and all is good in that regard. What I mean, is that shared code stacktrace is close to useless for iOS.
a
What's useless about it specifically?
e
You cannot trace back the actual exception with your source code
a
Why?
e
Are we on some sort of interrogation? 😄 I have no clue, why. I can see that issue arrises from shared code, but specifics - where exactly, like for android stacktrace - class/line, are not there.
a
Yeah, in a way, I am trying to pinpoint exactly what's wrong from your description. It still sounds like you don't have the kotlin debug symbols
e
Here is an example of uncaught exception:
Copy code
Thread 0 Crashed:
0   libsystem_kernel.dylib          0x3be10a2d4         __pthread_kill
1   libsystem_pthread.dylib         0x430cfc598         pthread_kill
2   libsystem_c.dylib               0x32b0a7b04         abort
3   shared                          0x1022dad30         (anonymous namespace)::terminateWithUnhandledException::lambda::operator()
4   shared                          0x1022dac50         (anonymous namespace)::lambda::operator()<T>
5   shared                          0x1022daa48         (anonymous namespace)::terminateWithUnhandledException
6   shared                          0x1022daa34         (anonymous namespace)::processUnhandledException
7   shared                          0x10173f204         [inlined] kfun:kotlinx.coroutines.internal#propagateExceptionFinalResort{} (CoroutineExceptionHandlerImpl.kt:23)
8   shared                          0x10173f204         [inlined] kfun:kotlinx.coroutines.internal#handleUncaughtCoroutineException{} (CoroutineExceptionHandlerImpl.common.kt:48)
9   shared                          0x10173f204         kfun:kotlinx.coroutines#handleCoroutineException{}
10  shared                          0x10173435c         kfun:kotlinx.coroutines.StandaloneCoroutine.handleJobException#internal (Builders.common.kt:191)
11  shared                          0x1017490cc         [inlined] kfun:kotlinx.coroutines.JobSupport#handleJobException{}kotlin.Boolean-trampoline (JobSupport.kt:1139)
12  shared                          0x1017490cc         kfun:kotlinx.coroutines.JobSupport.finalizeFinishingState#internal (JobSupport.kt:222)
13  shared                          0x10174efd0         [inlined] kfun:kotlinx.coroutines.JobSupport.tryMakeCompletingSlowPath#internal (JobSupport.kt:946)
14  shared                          0x10174efd0         kfun:kotlinx.coroutines.JobSupport.tryMakeCompleting#internal (JobSupport.kt:894)
15  shared                          0x10174e8dc         [inlined] inlined-out:<T> (JobSupport.kt:859)
16  shared                          0x10174e8dc         [inlined] inlined-out:loopOnState (JobSupport.kt:170)
17  shared                          0x10174e8dc         kfun:kotlinx.coroutines.JobSupport#makeCompletingOnce{}kotlin.Any? (JobSupport.kt:858)
18  shared                          0x1017316b8         kfun:kotlinx.coroutines.AbstractCoroutine#resumeWith{} (AbstractCoroutine.kt:98)
19  shared                          0x10164d390         [inlined] kfun:kotlin.coroutines.Continuation#resumeWith{}-trampoline (Continuation.kt:26)
20  shared                          0x10164d390         [inlined] inlined-out:<T> (ContinuationImpl.kt:43)
21  shared                          0x10164d390         [inlined] kfun:kotlin#with{0§<T>;1§<T>}0:1 (Standard.kt:70)
22  shared                          0x10164d390         kfun:kotlin.coroutines.native.internal.BaseContinuationImpl#resumeWith{} (ContinuationImpl.kt:26)
23  shared                          0x10178dc94         [inlined] kfun:kotlin.coroutines.Continuation#resumeWith{}-trampoline (Continuation.kt:26)
24  shared                          0x10178dc94         [inlined] kfun:kotlin.coroutines#resume__at__kotlin.coroutines.Continuation<T>{0§<T>} (Continuation.kt:45)
25  shared                          0x10178dc94         [inlined] inlined-out:<T> (DispatchedTask.kt:101)
26  shared                          0x10178dc94         [inlined] kfun:kotlinx.coroutines#withContinuationContext{0§<T>}0:0 (CoroutineContext.kt:44)
27  shared                          0x10178dc94         kfun:kotlinx.coroutines.DispatchedTask#run{} (DispatchedTask.kt:83)
28  shared                          0x1017afabc         [inlined] kfun:kotlinx.coroutines.Runnable#run{}-trampoline (Runnable.kt:10)
29  shared                          0x1017afabc         [inlined] kfun:kotlinx.coroutines.DarwinMainDispatcher.dispatch$lambda$0#internal (Dispatchers.kt:40)
30  shared                          0x1017afabc         [inlined] kfun:kotlinx.coroutines.DarwinMainDispatcher.$dispatch$lambda$0$FUNCTION_REFERENCE$1.invoke#internal (Dispatchers.kt:39)
31  shared                          0x1017afabc         kfun:kotlinx.coroutines.DarwinMainDispatcher.$dispatch$lambda$0$FUNCTION_REFERENCE$1.$<T>invoke{}#internal (Dispatchers.kt:39)
32  shared                          0x1022c83a8         ___6f72672e6a6574627261696e732e6b6f746c696e783a6b6f746c696e782d636f726f7574696e65732d636f72652f6f70742f6275696c644167656e742f776f726b2f343465633665383530643563363366302f6b6f746c696e782d636f726f7574696e65732d636f72652f6e617469766544617277696e2f7372632f44...
33  libdispatch.dylib               0x32afa6244         _dispatch_call_block_and_release
34  libdispatch.dylib               0x32afa7fa4         _dispatch_client_callout
35  libdispatch.dylib               0x32afb6a30         _dispatch_main_queue_drain
36  libdispatch.dylib               0x32afb6648         _dispatch_main_queue_callback_4CF
37  CoreFoundation                  0x31b4bdbb8         __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__
38  CoreFoundation                  0x31b4ba1ac         __CFRunLoopRun
39  CoreFoundation                  0x31b50c270         CFRunLoopRunSpecific
40  GraphicsServices                0x3b58c54bc         GSEventRunModal
41  UIKitCore                       0x320872778         -[UIApplication _run]
42  UIKitCore                       0x320498e60         UIApplicationMain
43  SwiftUI                         0x32454265c         closure in KitRendererCommon
44  SwiftUI                         0x32454258c         runApp<T>
45  SwiftUI                         0x324542470         App.main
46  airBaltic                       0x20053b69c         [inlined] iOSApp.$main
47  airBaltic                       0x20053b69c         main
48  <unknown>                       0x1beb50de8         <redacted>
Not sure what I am missing, but this just does not help me in finding the root cause of the crash.
a
ah, ok, I see
f
you can’t read a Kotlin/iOS trace like an iOS trace. A SwiftUI stack is worse than that.
true 1
@Edgars Malahovskis this crash is not correctly handled
a
Yeah, I was just going to link that project as well 😃
e
I know that this crash is not handled correctly, since it was uncaught exception. I do not think that this is even possible/needed. But essentially what I would like to achieve here, is to understand root cause of such crashes.
f
a
Check out the linked library, it may adress this on a general level. I haven't tried it myself because I just discovered it as part of this discussion. But I will now for sure
➕ 1
e
Ok, thanks guys for advice, will have a look. ✊
a
just found this in their release history though
e
I am using sentry for multiplatform, this does exactly what we see
a
ok, in my case, we are using sentry in the app layers, but we don't have the plugin/sdk in the shared code
f
I don’t know how sentry support crash I don’t see it in the documentation.
a
e
f
it’s using the same code as NSExceptionKit
r
@Edgars Malahovskis are you sure debug symbols are uploaded for 
iosApp
? we'd usually show a warning on top of the issue if there are missing dsyms
e
@romtsn Yes, dsyms are uploaded.
r
would you be able to share the event publicly? wondering how it looks in sentry
e
No, will not publish it, already added stack trace and explained, that DSYM is uploded.
g
@Edgars Malahovskis could you provide details on how you initialize the SDK in the native ios layer? are you swizzling it perhaps?
if your stacktrace looks like this that means the unhandled exception handling that you posted the snippet from is not invoked (I can reproduce it) and that often happens if people don't use the init function that we provide from the KMP SDK but rather use the native SDK init instead or if they swizzle it
e
@Giancarlo Buenaflor hi! Yes, I am initializing using native sdk. Reason for it is that, by some reason when I do multiplatform init, no events are sent to sentry.
Copy code
expect fun initializeSentry()
where ios actual
Copy code
actual fun initializeSentry() {
    Sentry.init {
        with(it) {
            dsn = "someURL" // hidden 
            attachScreenshot = true
            attachViewHierarchy = true
            environment = if (BuildConfigData.sharedEnvKey == "prod") {
                "production"
            } else {
                "demo"
            }
            sampleRate = 1.0
            tracesSampleRate = 0.1
        }
    }
}
and I call it in AppDelegate SentryHelper_iosKt.initializeSentry()
No events are sent with this configuration
g
how do you test that it's not sending events? do you use xcode and then throw some error to crash the app?
e
I crash the app from common code
Not sure is it relevant, but ios debug allways throws: Can’t show file for stack frame : <DBGLLDBStackFrame: 0x33d9f0d40> - stackNumber:7 - namekfunio.sentry.kotlin.multiplatform.nsexception.wrapUnhandledExceptionHook$lambda$0#internal. The file path does not exist on the file system: /Users/runner/work/sentry-kotlin-multiplatform/sentry-kotlin-multiplatform/sentry-kotlin-multiplatform/src/appleMain/kotlin/io/sentry/kotlin/multiplatform/nsexception/UnhandledExceptionHook.kt
g
do you use xcode to compile and run the app? I'm asking because often for crashes when using xcode it stops the app before Sentry can capture it
e
Yes, I use xcode, but app is crashing after app is initialized
app is normally launched and a button triggers a crash
g
yeah that's expected then, when it crashes xcode interferes with the app processing so Sentry won't get a chance to capture and send the crash, see this issue not really a KMP issue, you can try building the app with xcode, stop the debug connection and then use the simulator to open and crash the app and then re-open the app. that way xcode won't interfere we've had a similar report a while back
e
same result after disconnecting debuger
launch the app, crash it… still no events are sent
Not sure, what on earth is going on, but with setup from documentation, even android stopped sending any crashes to sentry.
r
there's an ongoing incident currently 🙈 https://status.sentry.io/
g
since the incident is fixed have you had the chance to try it out again?
e
@Giancarlo Buenaflor Seems that during the night, logs have reached sentry and are now showing up in dashboard. But today, when I am trying to send debug files to sentry, since yesterday I did not upload any files from local builds… same issue is back, errors are not poping up in sentry.
g
hm this sounds like an ingestion issue rather than SDK, if you don't mind you can create an issue in the sentry KMP repo so we can track this properly
e
@Giancarlo Buenaflor Ok, after few minutes they do appear. But with debug files uploaded everything from shared module of my app is redacted:
Copy code
OS Version: iOS 18.3 (22D63)
Report Version: 104

Crashed Thread: 0

Application Specific Information:
List is empty.

Thread 0 Crashed:
0   shared                          0x106b2e124         <redacted>
1   shared                          0x10723ada8         <redacted>
2   shared                          0x10723d8ac         <redacted>
3   shared                          0x107333728         <redacted>
4   shared                          0x107333d3c         <redacted>
5   shared                          0x107334dc0         <redacted>
6   shared                          0x1073317d4         <redacted>
7   shared                          0x106b05400         <redacted>
8   shared                          0x106c46320         <redacted>
9   shared                          0x106c688dc         <redacted>
10  shared                          0x10779a870         <redacted>
11  libdispatch.dylib               0x3176dc244         _dispatch_call_block_and_release
12  libdispatch.dylib               0x3176ddfa4         _dispatch_client_callout
13  libdispatch.dylib               0x3176eca30         _dispatch_main_queue_drain
14  libdispatch.dylib               0x3176ec648         _dispatch_main_queue_callback_4CF
15  CoreFoundation                  0x307bd7bc8         __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__
16  CoreFoundation                  0x307bd41bc         __CFRunLoopRun
17  CoreFoundation                  0x307c26280         CFRunLoopRunSpecific
18  GraphicsServices                0x1d23014c0         <redacted>
19  UIKitCore                       0x30cf92670         -[UIApplication _run]
20  UIKitCore                       0x30cbb8e84         UIApplicationMain
21  SwiftUI                         0x310c67ef4         closure in KitRendererCommon
22  SwiftUI                         0x310c67e24         runApp<T>
23  SwiftUI                         0x310c67d08         App.main
24  airBaltic Demo                  0x1047cd1c8         <redacted>
25  <unknown>                       0x1ab2edde8         <redacted>
that is… the most important information is redacted. Any options that I am not aware, to remove this behaviour?
g
How did you upload the debug files? / which method did you use
e
fastlane -> sentry_debug_files_upload
g
and you're sure that you did this in this order build app -> upload dsyms -> then trigger crash also when you uploaded successfully you should see under images loaded the 
shared
image
e
hmmm, interesting part here. Although dsym for shared module is created, it is not uploaded. No idea why fastlane is skipping this. I can see that 11 files are uploded and visible in sentry, but shared is missing.
g
this is on the event page
e
But order is correct
g
interesting, tbh I'm not too familiar with the fastlane codebase, it may be worth creating an issue there https://github.com/getsentry/sentry-fastlane-plugin and I can relay to our team to triage this more quickly
I'll try to see what's the issue meanwhile
could you try using xcode build phase to see if the problem persists?
just so we are sure that we can narrow down the issue to our fastlane plugin
e
I will try, but cant remember why we decided not to use directly sentry-cli. There was something with script method override if not mistaken. But will give it a go.
🙏 1
g
thx!
e
@Giancarlo Buenaflor did not try sentry-cli yet, but tried building and publishing app via CI, that also uses fastlane with sentry-cli bundled inside (older version 1.19.0, not the latest one I used locally). That uploaded all the missing dsym files and finally I can see propper stack trace! Maybe some time later will try to figure out why local deployment does something else, but for now: thanks a lot for your assistance and help.
👍 1
g
cool! let me know if you need more help or feel free to open an issue in the KMP repo
🙌 1
26 Views
Open in Slack
PreviousNext
Powered by