https://kotlinlang.org logo
Join Slack
Powered by
We’re running into a frustrating crash. The messag...
# kotlin-native
k
We’re running into a frustrating crash. The message is “Fatal Exception: ExceptionObjHolder”. The full stack trace is here
Anyway, wondering if there are any thoughts about tracking this down, and if the missing lines 9-14 are likely kotlin code, and improved crash reporting would be expected to make them not missing?
o
well, as usual reproducer would be amazing, generaly 
ExceptionObjHolder
is C++ object holding reference to Kotlin exception being thrown
k
Yeah, new client. Just got the code and they’re like, “what’s this?” Trying to make a repro now.
🙏 1
Do you think the code in lines 9-14 is kotlin? We have been doing some work in the crash reporting space, so I can try to have them turn on better reporting, but it’ll be a while before we see anything, unless I can figure out a direct repro: https://github.com/touchlab/CrashKiOS
o
seems Kotlin exceptions reached top level handler and reported as unhandled
k
Yeah, that’s what I was thinking, but I’m surprised the stack is completely missing. Looking into the build now.
r
Oh, I saw some of those myself recently. Didn’t bother to really check as I had no info on Bugsnag
k
If configured correctly, you should be able to push to bugsnag and crashlytics (see https://github.com/touchlab/CrashKiOS above). What I don’t have a solid handle on is what info do you get without that config. Looking to see if I can reproduce an empty stack trace with a similar signature
r
I think it was just OOM or StackOverflow errors not being properly reported for unknown reasons
Because I’ve got this kind of things in one of the threads on the error
k
I would expect neither to be “properly reported” as they’re probably handled by the host runtime directly (at least this is how J2objc used to operate. Assume KN would act similar, but haven’t tried that in prod)
t
I have the same exception but in my case the stack trace is complete. Any idea what this could be?
Hi @kpgalligan, were you able to figure out the cause of this exception?
k
I don’t see anything related to Kotlin in there. The only thing that’s not part of an iOS library is SceneFadeSheet.swift, Line 6
t
SceneFadeSheet.swift is a class I made, for some reason that appears at the bottom of every stack trace. I don’t know why, but it probably isn’t related here.
k
Oh, missed the top.
👍 1
t
So even though ExceptionObjHolder is a Kotlin class, do you think it is not actually caused by the Kotlin framework?
k
We never figured out the root cause of that issue, although today the client said they made some progress on avoiding it, which we still need to look into, but probably not for a bit. Have a bunch of other stuff as priority
t
Ok, appreciate your help. If there is anything I could try please let me know! Currently this is the top crash in Crashlytics so I would really like to solve it.
k
Really, damn
s
Please check crash reports provided by Apple in Xcode. These reports may contain proper stack trace. Try to report unhandled Kotlin exceptions to Crashlytics using https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.native/set-unhandled-exception-hook.html
t
@svyatoslav.scherbina Good idea! I just checked Xcode and found the following which looks similar.
I am already reporting unhandled Kotlin exceptions to Crashlytics with CrashKiOS. Do you mean that this is the fatal exception for all unhandled Kotlin exceptions? There is another type of exception on Firebase which shows TerminateWithUnhandledException in the stack trace. So I don’t think that this exception is related to unhandled exceptions.
s
Good idea! I just checked Xcode and found the following which looks similar.
Yes, but there are frames from “common”. Do you have 
.dSYM
for it?
Do you mean that this is the fatal exception for all unhandled Kotlin exceptions?
No, for some of unhandled Kotlin exceptions. For example, for exceptions thrown out of Kotlin lambda called from Swift or Objective-C. Anyway, 
setUnhandledExceptionHook
helps to detect these exceptions too.
And your stack trace looks much like if GCD tried to call a lambda, it threw a Kotlin exception, so GCD terminated the process then.
t
Yes, but there are frames from “common”. Do you have 
.dSYM
for it?
Yes it should be available. I am not sure why Xcode doesn't use it.
And your stack trace looks much like if GCD tried to call a lambda, it threw a Kotlin exception, so GCD terminated the process then.
Ok, in that case I will keep fixing the unhandled Kotlin exceptions (still have some left on Firebase) and will see if this crash goes down in the list. Appreciate your help!
s
Hi guys! I have included CrashKiOS in my multiplatform solution and I have generated some crashes in the kotlin side. The crash appears as non blocking in firebase (I think is the current behavior in the CrashKiOS solution) but stacktrace messages appear empty with a label telling me something is missing. The dsym file seems to be uploaded correctly, any idea what I'm doing wrong?
message has been deleted
This is the stacktrace of the error
"presentation" is the name of the ios framework generated from the kotlin side
@kpgalligan did you manage to solve the issue with the empty stacktrace?
k
It’s not on the CrashKios side of things. The library just sends the stack addresses to crashlytics. To get that to work, you’ll need to config the optimization level as described in the docs, but then also make sure the dsyms are being included appropriately, which is part of the build setup. It’s possible that if you’re using the cocoapods plugin, it’s not wrapping the dsyms because it’s a static framework. We had that issue with local debugging. I haven’t tested that and crash reporting, but ultimately the actual “CrashKiOS” is doing very little (sends stack pointer addresses), so there’s not much to “fix” there. It’s all config.
s
Is it obligatory to define the framework as static?
I'm uploading the dsym file of the framework correctly, firebase is not complaining about missing dsym files at least
k
The cocoapods plugin for kotlin defines a static framework. We just forked it so we could make some tweaks. That may not be necessary to get dsyms, but Xcode debugging wasn’t working prior to making it a dynamic framework.
In this particular situation, the only difference between static and dynamic is that a static framework just has the binary, and a dynamic has a bunch of other stuff, including dsyms for that part of the binary.
It’s like the difference between a jar and an aar
dsym files are particular to binary, so (I believe) it’s possible to have some of them but not all of them
s
Ok, I'll try making the framework static
Instead of retrieving stacktrace, is it possible to get the Throwable object with Crashkios?
Do you have any example in that case?
k
“Ok, I’ll try making the framework static” Static is the issue. Dynamic includes the dsym files. KaMP Kit has our forked cocoapods plugin: https://github.com/touchlab/KaMPKit/blob/master/shared/build.gradle.kts#L96
“Instead of retrieving stacktrace, is it possible to get the Throwable object with Crashkios?” All we’re really doing is listening for a default exception handler, and pushing that to crashlytics. You can also register a default exception handler and print the throwable, but to send it to crashlytics and have it symbolicated you will need the dsym info. You can just print the stack trace to the crashlytics log, but that loses symbolication
s
Currently I'm generating the framework manually using a gradle task and then I copy it together with the symbols to the iOS folder. The framework is dynamic thus.
I will check the KaMPKit anyway
k
Hmm
That’s different. Not sure then.
s
I'll try including the framework via cocoapods, don't worry, thanks :-)
20 Views
Open in Slack
PreviousNext
Powered by