https://kotlinlang.org logo
Join Slack
Powered by
Anybody else see crashes in Xcode when breakpoints...
# kotlin-native
t
Anybody else see crashes in Xcode when breakpoints are set and using a Kotlin MPP framework. Not breakpoints in the Kotlin code, just in the ObjC/Swift code. If I unset the breakpoints and run again, it is fine.
k
Crash listing?
t
Yes, I have this too. When settings breakpoints in Swift code, then resuming, Kotlin just crashes randomly. Without breakpoints I do not have any issues
k
Kotlin version? Crash detail? The xcode plugin is not doing much besides telling xcode that kotlin is a source file and some llbd init, so I’m not sure how helpful I’ll be, but if people are generally seeing this, it’s something to look at (I haven’t seen this)
t
I am currently using 1.3.50. Don't think this was happening in 1.3.40. I can't provide a stack trace right now, but I know they are completely random every time (at least for me)
k
I’ll definitely need some kind of a stack trace, or (better) a small sample that can reproduce the issue that I can run.
t
Thread 1: EXC_BAD_ACCESS (code=1, address=0x7ffe64ceed78)
Untitled
This is Kotlin 1.3.50, ktor 1.2.5. Likely wont be able to construct a small sample.
k
The stack trace doesn’t say much, other than it’s crashing when collecting memory. If you can construct a sample I assume you can’t post the code where this is happening? It happens when you debug in Swift? The call is coming from ktor, so are you making a network call then breaking in swift?
The “xcode plugin” just tells lldb where to stop. This could be a weird lldb/debug thing, but I’d put my money on some kind of race condition.
t
Correct. This particular callback is in response to when the network call has completed.
i installed the xcode plugin in an older xcode (11.0 I think). Is it still active in this version? (11.2.1). Should I do an update to latest?
k
Describe the situation. You are in main thread in Swift, make a call from main thread to kotlin, all in the main thread, and return on the main thread?
t
I have never actually gotten to the point of debugging Kotlin in Xcode, but if I could that would be sweet.
k
It is unlikely to be “caused” by the plugin. The plugin does not do much.
t
I did not think so.
k
Oh, wait
Completely remove the kotlin plugin from xcode, then run this again. You’re not debugging kotlin, right? Just to “prove” it’s not the plugin. Again, it really doesn’t do much.
t
sorry, i do not recall how to remove…
k
The kotlin xcode plugin exists to debug in kotlin
t
Maybe in one of your talks you can give a demo of debugging a Kotlin MP framework in Xcode. 🙂
k
The plugin script copies some files to the file system. Remove them. If not all that, just remove 
~/.lldbinit-Xcode
I have, just I guess not a very public one.
Remove that file, 
~/.lldbinit-Xcode
. That adds some stuff to lldb. If the code is still crashing, this is definitely some form or race condition with Kotlin and ktor and not the plugin. It’ll be pretty difficult to debug without something to run locally
t
Understood. If I ever work on a small app again, I will try to repro.
FYI, same crash after removing that file. As mentioned, we do not see it without the breakpoint. That is, production code appears to work fine so far. After all the libs are updated for 1.3.60 I will try there again.
t
After trying to get the crash myself, I got a similar stack trace. Here are the first 20 lines:
Untitled
k
You’re using flow. From what?
t
Well I am using Flow everywhere throughout my app. What exactly do you want to know?
Do you want a complete stack trace?
k
Is all flow usage on the main thread? The code you’re calling would be useful. The summary is this isn’t going to be an Xcode Plugin issue. I’m guessing this is a threading issue, but it could also be something else.
By “The code you’re calling would be useful” I mean the stack trace is interesting, but in general seeing the code is going to be necessary, and some kind of minimal repro project ideal.
t
All flow usage I coded is on the main thread. It’s difficult for me to show the code as I don’t know where it is happening. The crash only happens after resuming a break point in Swift, so I have no idea where it is happening. Sometimes it even takes a few seconds after resuming the breakpoint to crash.
Unfortunately the line numbers in the stack trace don’t really match my code, but it points to a file where I create a flow and collect it. Not really anything special I think
k
OK. Well, same message as to Tyler. You can remove the Xcode Kotlin Plugin, and I’m 99.9% sure you’ll still have the crash, as you’re actually putting the breakpoint in Swift. I suspect there’s some form of race condition, but it’ll be extremely hard to debug without a repro of some type. A minimal example app, hopefully, that can be shared. We ran into something similar-ish a while back(https://github.com/JetBrains/kotlin-native/issues/3353). I doubt it’s the same thing, but without some code to poke at it’ll be very difficult to identify.
If all of your flow code is in the main thread, is any part of your app doing concurrency, and how?
t
I don’t think so. I am using Ktor and SQLDelight in my project, not sure what they do. Coroutines is used a lot and have my own implementation of CoroutineDispatchers which uses dispatch_async/dispatch_after, but still all on the main thread. Furthermore the code is shared with JVM, so I am using Mutex with locking at some points, but I guess that shouldn’t really do anything in KN if it is only accessed from the main thread.
k
SQLDelight will do nothing out of the box if you don’t tell it to operate on a different thread, although in theory you don’t want to be doing db operations on the main thread, but that’s a different discussion.
Ktor does run calls on a different thread, but the return is on the main thread, so assuming you call it from the main thread, OK
Wait, I may be wrong. Which methods are you calling on SQLDelight?
t
I am only using SDLDelight for some basic calls like select. delete, insert. Nothing special with Flow or so. And it’s all on the main thread for now but that is not the biggest issue at the moment.
k
SQLDelight flow implementation will use the default dispatcher for some methods, which won’t work in 1.3.50 and earlier. It should work on 1.3.60 with multithreaded coroutines preview. I’m trying to work on that now, actually
t
Yeah, I am not observing the database anywhere
k
OK. I don’t have any other ideas. Would need to be able to repro locally.
t
Ok, appreciate your thoughts. I will see what happens when I update to Kotlin 1.3.60 in the coming days/weeks
FYI here is another stack trace I got (still Kotlin 1.3.50). This stack trace does not reference Coroutines (although Coroutines were created somewhere else at this point). I set a breakpoint in my AppDelegate application didFinishLaunchingWithOptions function. Then I resumed the breakpoint. Then after that my “BaseViewModel” class got created. That class logs a message after initialization using the Kotlin 
println
function (via my own Tree.log function).
Untitled
Just updated my project to Kotlin 1.3.60 and haven’t been able to reproduce this issue so far. Will keep you updated!
a
Hey @Thomas how did you go with debugging? I'm having the same issue - cannot debug common code in xcode.
t
@Aleksey Chugaev the issue disappeared for me completely after updating to Kotlin 1.3.60.
a
I'm on 1.3.61 and debugging still doesn't work
2 Views
Open in Slack
PreviousNext
Powered by