I recently started seeing a crash in Crashlytics for my Android app regarding a Job getting cancelled, but it has no stacktrace. It happens when backgrounding the app, but only very rarely, so it's very difficult to track down what's actually happening. Here's the exception (it's just one line):

Fatal Exception: JobCancellationException: Job was cancelled

Is there any sort of global debugging I can turn on to try and track this down? If so, are any of them safe for a production environment?

This is weird. It should have had a strack-trace.

I and @jw also had this happen to us back in the past in Android apps. Makes finding the root cause no longer a beginner affair.

If there anything that could be tweaked to get a strack-trace? What could even cause the absence of a track-trace? VM problem? Out of memory?

I don't think it's OOM. At least not in my scenario

Can it be the fact that the Android artifact of kotlinx.coroutines directly calls into

Thread.UncaughtExceptionHandler

instead of letting the exceptions/throwables be actually uncaught?

It should not cause the missing stack-trace, because normally UEH logs exception with stacktrace.

Could it be related to this https://developer.android.com/about/versions/oreo/android-8.0-changes#loue

Did you get the full stacktrace?

I'd not be surprised if that was related to

offer

throwing before called after close, but before callback unregistering had a chance to happen. Last time I had the issue, this was the culprit. It's even nastier when that happens in non suspending function that is called from suspending function as the program/app doesn't crash, but some code is not executed, and you don't know why, until you hopefully find some code was calling

offer

on a cancelled/closed channel (e.g. because the scope of an

actor

was closed, or whetever). As a reminder, this related issue has been reported almost a year ago: https://github.com/Kotlin/kotlinx.coroutines/issues/974#issuecomment-577732745 This would be less of an issue if there was an inspection, or a checked exception that the compiler would enforce, but that's not the case, and that makes code unsafe until people realize the issue. Also, the example in the documentation of

callbackFlow

promotes an unsafe example as when there's asynchrony in callback unregistering, or multiple threads involved (like so often on Android and in the JVM), the

offer

call would crash in the cases there was a callback happening at that time. So yes, I'm trying to urge you to treat that as a design issue rather than just an "enhancement", and to fix that before Kotlin 1.4, by whatever mean (warning at use site is very conservative, but better than nothing).

@elizarov nope that's all there is @louiscad thanks for the info. I'll see if this leads me anywhere

@eygraber You can use "Replace in Path" to replace with something like the extension I show in the initial post of the issue. Then, all you'll need is to fix the imports. If you don't use star imports, that just means using "Replace in Path" for the import as well, and then, ensure all the modules of your project build.

Cooler heads prevail I suppose 😁

I'm very glad!