What are some strategies for debugging Kotlin/Nati...
# kotlin-native
What are some strategies for debugging Kotlin/Native on Linux and Windows? I've found it pretty difficult to get any stack trace at all (let alone with line numbers) at times, having to resort to inserting log statements just to narrow down the line that causes the crash. It can be a fun challenge at times, but definitely not very efficient use of time. ­čžÁ with my latest crash output from a failing test on Linux.
When I run the failing test with gradle:
Copy code
./gradlew clean :lib-module:linuxX64Test --tests package.TestClass.testName
This is the output:
Copy code
> Task :lib-module:linuxX64Test FAILED

package.TestClass.testName[linuxX64] FAILED

1 test completed, 1 failed

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':lib-module:linuxX64Test'.
> Test running process exited unexpectedly.
  Current test: testName
  Process output:
   <standard output logs...>

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.

* Get more help at <https://help.gradle.org>

With the error being
with no stack trace, I'm able to narrow the line that fails with log statements. But I don't even get a POSIX signal, let alone an exception to indicate what went wrong.
If I add
, I just get this stack trace for where Gradle crashed, where I can see
Test running process exited unexpectedly.
makes no difference. No stack trace either way.
Same result with both Kotlin 1.8.22 and Kotlin 1.9.0-RC.
This same test usually passes on Windows, which utilizes the same multiplatform
implementation code as Linux. It has also passed occasionally on Linux, but usually fails.
I just got it to fail on Windows too and got the same output, lacking crash details, as Linux.
Ok, I narrowed down this particular bug. It ended up being a race condition where I was disposing a
right before removing a native C listener that used it in a
callback. Removing the listener before disposing it fixes the problem. Oddly, after getting the underlying class reference with
, I could log the non-null field references just fine (logging
). It would crash with the
error if I tried to log the entire class reference or invoke the function, which one of the non-null fields holds.
I'm still interested in tips for Kotlin/Native debugging to avoid relying entirely on
log statements.
Welcome to the club ­čÖâ. Did plenty of logging back in the day for a commercial project using K/N and Linux. There is a tool called strace ( https://opensource.com/article/19/10/strace ) that can be used with K/N programs on Linux that shows all sys calls made by the program, which may be helpful for debugging purposes.