Kotlin compiler plugin to recover minimal stack trace of launch site

[SUPERCILEX]

#74 is targeted at full stack trace recovery for debug builds, but would it be possible to recover only the first few items on the stack at compile time? That way, this could be used in prod. The hardcoded stacktrace would stop at the first branch off point, but it would at least provide some context as to where a random crash came from. Currently, there's no way to know where the crash originated. Not sure how this would work with Proguard/R8.

WDYT? Is it possible? Would other people want this?

[fvasco]

Compute the stack at compile time is not possible.
A function (ie toString()) can be called multiple times by many methods, other functions can be recursive, with a potentially infinite stack trace.
As a prove, if every single method knows its stack at compile time, so every single method knows the caller method/line, there is no reason to store the invocation stack at runtime, because the compiler is able to put a GOTO (or similar) to the right point.

However is possible to include a stack trace (or a part of it) at runtime in the coroutine context, this can recovered, inspected and logged when required. This solution is subject to obfuscation.

Finally compiler can expose some intrinsic methods to recover the current source file name/current source line at build time, in such case the coroutineScope or coroutine builders can save in the scope a single stack frame.

[SUPERCILEX]

Finally compiler can expose some intrinsic methods to recover the current source file name/current source line at build time, in such case the coroutineScope or coroutine builders can save in the scope a single stack frame.

Yes, that's what I was referring to.

[elizarov]

It is hard. The plan for debugger support is to capture stacktraces only when a new coroutine is launches, which should not be happening that often, so it might be appropriate for use in prod in many cases.

[qwwdfsad]

Frankly speaking, the initial proposal is impossible, because multiple entry-points to a method typically exist.

Nevertheless, the compiler provides some kind of internal API to walk over continuations (at runtime, not statically) and we are leveraging it in #792.

Moreover, we have an even better solution: https://github.com/Kotlin/kotlinx.coroutines/tree/debug-agent/core/kotlinx-coroutines-core-test (without a PR yet, but it is actively evaluated internally).

I will close this issue as it is already covered b these two enhancements