Debugging process for the creators of custom libraries based on serialisation-core

[orchestr7]

I am working with ktoml - custom serializer for TOML format.
Our contributors sometimes need to debug our library and to see a full call stack of methods (including the stack to the core framework).

For example, we have an internal issue and would like to debug the following test to understand which core method calls our methods in the library:

Right now we are not able to see the stack to the serialization-core. Debugger only points to @Serializable annotation without any stack to real methods provided by serialization library.

We only know that "something" (generated code) calls methods from our library:

	at app//com.akuleshov7.ktoml.decoders.TomlAbstractDecoder.decodeLong(TomlAbstractDecoder.kt:85)
	at app//com.akuleshov7.ktoml.decoders.InlineDecoderTest$Color$$serializer.deserialize-klGe9qk(InlineDecoderTest.kt:10)
	at app//com.akuleshov7.ktoml.decoders.InlineDecoderTest$Color$$serializer.deserialize(InlineDecoderTest.kt:10)

=====================

Could you please help and propose any method for debugging that could help us to understand the call chain in serialisation-core? Also it would be very helpful for the community if there would be a small documentation for creators of serialization library (with such things like debugging, call chains, etc).

[pdvrieze]

@akuleshov7 That deserialize-klGe9qk is effectively the implementation of decoder part for the generated serializer (the owner type) for the Color value class. You will notice that is is invoked by the normally named deserialize function (also automatically generated). Both don't exist in source code so a debugger will not be able to display this source code. What you can do is use the bytecode viewer (and decompiler) to see what actually would be going on.

Generated decoders basically will first start to decode the (inline) structure, and inside loop to read the index of the next item to decode, if it is not DECODE_DONE it will then, based upon the actual index, call an appropriate decode... method on the decoder (setting a local variable with the value), once finish, close the struct and construct and return the parsed object.

[orchestr7]

@pdvrieze I know how the process works, I learnt it while we were making ktoml :) The problem is that we are not able to debug it properly in case of such corner cases. That’s why I am asking, if there is any convenient way of how to debug such problems easily.

How do new people, who do not understand how the core framework works, debug it?

[sandwwraith]

It is the problem that core library authors also experience :) Indeed, you can only navigate to the code that actually exists (pay attention this includes code from core runtime library, like AbstractDecoder, Decoder, etc — if you can't do that, check that you've correctly attached library sources. ) It is currently impossible to view or navigate to plugin-generated code automatically; and I can't promise that things will be changed in the nearest future (maybe this problem would be solved as a part of public plugin API).

It is currently possible to 'decompile to Java' as was suggested above; the most easy way is to do this in IDEA: Find compiled class in build/classes/kotlin, open it, hit Tools - Kotlin - Decompile Kotlin to Java (or use Find Action, Cmd-Shift-A).

You can also check out guide to custom composite serializers — layout of generated code is very similar to them.

[orchestr7]

@sandwwraith Lenya, you are the best, thank you for your answer. I actually missed the moment when there appeared "Decompile Kotlin to Java" functionality. This works pretty good, I can easily understand what is going on under the hood 😄 That helped, at least in my simple cases.

But actually, anyway I suppose that debugger team should make the support of navigation through the code generated by compiler plugins. Sounds good for JetBrains-research, isn't it? 😃