I have a fatal exception stack trace from our android app that looks like this -- it looks like some android event is triggering the type system in Kodein, and causing this error -- but I have no idea what the root cause might be. This is with Kodein 7.18.0 which appears to be using kaverit-jvm 2.3.0. Anyone have any ideas?

java.lang.StringIndexOutOfBoundsException: length=2; index=10
	at java.lang.String.substring(String.java:2060)
	at vg.l.g1(Unknown Source:31)
	at myapp.GlobalApplication$di$2$invoke$lambda$0$$inlined$bind$default$1.i(typeTokensJVM.kt:36)
	at myapp.GlobalApplication$di$2$invoke$$inlined$singleton$default$7.invoke(typeTokensJVM.kt:15)
	at androidx.compose.foundation.text.selection.SelectionMagnifierKt$rememberAnimatedMagnifierPosition$1$2.i(SelectionMagnifier.kt:94)
	at bh.g0.i(Unknown Source:169)
	at ge.b0.l0(Unknown Source:126)
	at kotlinx.coroutines.flow.internal.ChannelFlowTransformLatest$flowCollect$3$1$emit$1.invokeSuspend(Merge.kt)
	at kotlin.enums.EnumEntriesList.resumeWith(EnumEntries.kt:7)
	at yg.m0.run(Unknown Source:113)
	at androidx.compose.ui.platform.AndroidUiDispatcher.performTrampolineDispatch(AndroidUiDispatcher.android.kt:81)
	at androidx.compose.ui.platform.AndroidUiDispatcher.access$performTrampolineDispatch(AndroidUiDispatcher.android.kt:41)
	at androidx.compose.ui.platform.AndroidUiDispatcher$dispatchCallback$1.run(AndroidUiDispatcher.android.kt:57)
	at android.os.Handler.handleCallback(Handler.java:883)
	at android.os.Handler.dispatchMessage(Handler.java:100)
	at android.os.Looper.loop(Looper.java:214)
	at android.app.ActivityThread.main(ActivityThread.java:7405)
	at java.lang.reflect.Method.invoke(Native Method)
	at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:502)
	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:980)
	Suppressed: dh.g: [l1.m1@82d6cff, f0.e@ec74acc, y1{Cancelling}@96d3115, p0@3b07c2a]

If the line number is right, the exception is thrown from code called by https://github.com/kosi-libs/Kaverit/blob/bbb588d24a686199b0671d0bf5befc5c47797347/kaverit/src/jvmMain/kotlin/org/kodein/type/typeTokensJVM.kt#L36, but that doesn't seem to make much sense.

I don’t think this is related to the Kotlin version. BTW we are working on releasing it with recent versions of Kotlin, But we have some issue with the migration to AGP 8 for our internal Gradle Plugin.

Only because of the presence of

typeTokensJVM.kt

in the stack trace. But I really have no idea what is happening here, or even what is triggering this. I'm only seeing this in our crashlytics information -- I can't reproduce it on my own device.

Are you using set binding ?

@romainbsl No, not in this project

Ok, because the kaverit line you shared upfront is used in set binding only, so this is not related.

Hmm, I do import

androidXModule

-- could that be using a Set binding? That would also explain the apparently low-level call-in from Android to my DI bindings.

It does not.

What does

bind { Provider(TypeToken.Any, generic()) { app } }

in the

androidCoreModule

do?

It does bind the

Application

so it can be used as application context when needed

Probably an aside but: isn't a provider expected to return a new value each time? Why use a

provider

instead of a

singleton

here?

this is legacy code, it should be an Instance. But, as the lambda refers to the app instance, it’s like a factory returning the same instance. Not really consistent, I agree. But, it is probably not related.