In release mode, complete stack information cannot be obtained
In the release mode, the shared module has only 2 stack information, why ????
- 0 : "0 shared 0x000000010ec43178 ThrowArrayIndexOutOfBoundsException + 88"
- 1 : "1 shared 0x000000010ec49454 objc2kotlin.44 + 916"
- 2 : "2 SwiftUI 0x00007fff5732b576
...
in debug mode, we can get complete stack frame info :
- 0 : "0 shared 0x000000010b0a2241 kfun:kotlin.Throwable#<init>(){} + 65 (/Users/teamcity/buildAgent/work/cae0e6559deed4c4/runtime/src/main/kotlin/kotlin/Throwable.kt:27:21)"
- 1 : "1 shared 0x000000010b09c31a kfun:kotlin.Exception#<init>(){} + 58 (/Users/teamcity/buildAgent/work/cae0e6559deed4c4/runtime/src/main/kotlin/kotlin/Exceptions.kt:21:28)"
- 2 : "2 shared 0x000000010b09c42a kfun:kotlin.RuntimeException#<init>(){} + 58 (/Users/teamcity/buildAgent/work/cae0e6559deed4c4/runtime/src/main/kotlin/kotlin/Exceptions.kt:32:28)"
- 3 : "3 shared 0x000000010b09c96a kfun:kotlin.IndexOutOfBoundsException#<init>(){} + 58 (/Users/teamcity/buildAgent/work/cae0e6559deed4c4/runtime/src/main/kotlin/kotlin/Exceptions.kt:90:28)"
- 4 : "4 shared 0x000000010b09ca7a kfun:kotlin.ArrayIndexOutOfBoundsException#<init>(){} + 58 (/Users/teamcity/buildAgent/work/cae0e6559deed4c4/runtime/src/main/kotlin/kotlin/Exceptions.kt:97:21)"
- 5 : "5 shared 0x000000010b0d35ca ThrowArrayIndexOutOfBoundsException + 122 (/Users/teamcity/buildAgent/work/cae0e6559deed4c4/runtime/src/main/kotlin/kotlin/native/internal/RuntimeUtils.kt:23:11)"
- 6 : "6 shared 0x000000010b122a1d Kotlin_Array_get + 29"
- 7 : "7 shared 0x000000010b073165 kfun:com.banmalu.firstkmmdemo.shared.Greeting#greeting(){}kotlin.String + 885 (/Users/banmalu/AndroidStudioProjects/FirstKMMDemo/shared/src/commonMain/kotlin/com/banmalu/firstkmmdemo/shared/Greeting.kt:11:11)"
- 8 : "8 shared 0x000000010b07545b objc2kotlin.2 + 203 (-/<compiler-generated>:1:0)"
Hello, we have the same issue. We have a KMP project which builds an XCFramework with DSYMs. To build the XCFramework we first do a normal build, which generates arm64 and x64 .framework, then we use a task to generate the XCFramework:
tasks.register<Exec>("Make Release xcframework") {
group = "iOS frameworks"
// due to a bug of xcodebuild command, the dsym must be passed as an ABSOLUTE PATH, and not as relative path
// see https://developer.apple.com/forums/thread/655768?answerId=632625022#632625022
val dsymArm64 = File("build/bin/iosArm64/releaseFramework/IMC.framework.dSYM").absolutePath
val dsymX64 = File("build/bin/iosX64/releaseFramework/IMC.framework.dSYM").absolutePath
dependsOn("Delete release xcframework")
dependsOn("linkReleaseFrameworkIosArm64")
dependsOn("linkReleaseFrameworkIosX64")
executable("xcodebuild")
args(
"-create-xcframework",
"-framework",
"build/bin/iosArm64/releaseFramework/IMC.framework",
"-debug-symbols",
dsymArm64,
"-framework",
"build/bin/iosX64/releaseFramework/IMC.framework",
"-debug-symbols",
dsymX64,
"-output",
"build/xcode-frameworks/release/IMC.xcframework"
)
}
Then, via CI, we publish it on CocoaPods and upload DSYMs on Crashlytics. We integrate the cocoapod on our app (with no bitcode enabled), upload the app on AppDistribution and let it crash with a method called in KMP. Crashlytics shows no stacktrace, even though it doesn't say anything about missing DSYMs. We followed the CrashKiOS readme, but we still can't see crashes in release mode. We tried using a .framework instead of an XCFramework, but nothing. Is there something we might be missing?
Thanks.
@MovementSpeed Your framework should be static to get symbolicated crash reports: https://kotlinlang.org/docs/native-ios-symbolication.html#make-frameworks-static-when-using-rebuild-from-bitcode
@MovementSpeed Your framework should be static to get symbolicated crash reports: https://kotlinlang.org/docs/native-ios-symbolication.html#make-frameworks-static-when-using-rebuild-from-bitcode
He didn't enable bitcode, So there is no need to set framework to static I think
This is a general concern we're going to dig more into soon. We generally use static frameworks internally, so we don't run into problems much. We'll see if we can repro and provide instructions.
Most of our ongoing work in crash reporting is in Kermit, so that gets the bulk of the attention, but the problems are the same.
Closing an old issue. Feel free to re-create one with the latest version if the problem still exists.