Hello, I'm getting this surprising `ArrayIndexOutO...
# compose-desktop
l
Hello, I'm getting this surprising
ArrayIndexOutOfBoundsException
when
ImageComposeScene.use { … }
exits. Could it be caused by Compose Hot Reload, or is it something different? This is with Compose Hot Reload 1.0.0-alpha09 and Compose 1.8.0-rc01 on macOS.
Copy code
Index -331 out of bounds for length 640
java.lang.ArrayIndexOutOfBoundsException: Index -331 out of bounds for length 640
	at androidx.compose.runtime.SlotWriter.moveSlotGapTo(SlotTable.kt:4174)
	at androidx.compose.runtime.SlotWriter.removeSlots(SlotTable.kt:2904)
	at androidx.compose.runtime.SlotWriter.removeGroup(SlotTable.kt:2021)
	at androidx.compose.runtime.ComposerKt.removeCurrentGroup(Composer.kt:4337)
	at androidx.compose.runtime.CompositionImpl.dispose(Composition.kt:840)
	at androidx.compose.ui.layout.LayoutNodeSubcompositionsState.disposeCurrentNodes(SubcomposeLayout.kt:638)
	at androidx.compose.ui.layout.LayoutNodeSubcompositionsState.onRelease(SubcomposeLayout.kt:450)
	at androidx.compose.ui.node.LayoutNode.onRelease(LayoutNode.kt:1428)
	at androidx.compose.runtime.internal.RememberEventDispatcher.dispatchRememberObservers(RememberEventDispatcher.kt:163)
	at androidx.compose.runtime.CompositionImpl.dispose(Composition.kt:843)
	at androidx.compose.ui.scene.BaseComposeScene.close(BaseComposeScene.skiko.kt:128)
	at androidx.compose.ui.scene.CanvasLayersComposeSceneImpl.close(CanvasLayersComposeScene.skiko.kt:194)
	at androidx.compose.ui.ImageComposeScene.close(ImageComposeScene.skiko.kt:178)
s
If it shows up after reloading code then I would be very interested what the change was. If it's failing straight on startup w/o any reloads, then it's not likely.
Of course I am still interested in the code anyways! If it works w/o the chr plugin applied, but w/o relaods then it could also be the Gradle plugin having issues with dependencies?
l
I'll try with the disabled plugin, and see if it can reproduce it. It's a random issue, but it occured quite a bunch of times yesterday night
s
Ok! Thanks a lot! If it happens after reloading then it can certainly be the case if CHR did not invalidate a 'dirty' composable
l
It was happening with normal run
s
The invalidation resolver is wip and we're super eager to find issues to further stabilize it!
l
That said, I was wondering if it could still have any impact, including maybe caused by the fact that IntelliJ is designed to saves files (not sure if it's done systematically) on lost of focus
s
Hmm, if it happens in normal mode than me, as CHR maintainer, am relieved, but me as Kotlin Department Engineer, is still concerned
😄 1
Compose Hot Reload could lead to an issue exactly then when dirty code is not invalidating the slot table. If this happens it's a pure bug and we have to fix this. Other than that : reloading code might always come with the risk: previous states which the app is in, might not be legal/expected by the new code
l
Just reproduced again with CHR enabled. FYI, the numbers are always different, when it happens:
Index -171 out of bounds for length 640
BTW, it's a project I can share privately if needed
s
That might be very helpful! I can sign NDA if needed also
l
Damn, what's that… 🙈
Experimental KMP 2019 vibes 😅 (Except that redoing a Gradle sync fixes it)
s
Flashback
😄 1
Still gives me shivers. Hardest time of my life
😬 1
l
For disabling Compose Hot Reload, do I also need to remove it from the classpath entirely, i.e. removing that
alias(libs.plugins.composeHotReload) apply false
from the root
build.gradle.kts
file?
s
No, if it's not applied it should not do anything
1
l
Good, fewer changes to try back and forth 🙂
Reproduces without CHR 😅
It led to a cascade of exceptions this time, but same root cause, and interestingly exactly the same values as the last try with CHR:
Index -171 out of bounds for length 640
s
Try with --no-build-cache --no-configuration-cache --rerun-tasks
l
The other errors:
Copy code
ClassCastException: class androidx.compose.foundation.layout.FillNode cannot be cast to class androidx.compose.foundation.text.modifiers.TextStringSimpleNode (androidx.compose.foundation.layout.FillNode and androidx.compose.foundation.text.modifiers.TextStringSimpleNode are in unnamed module of loader 'app')
And this one:
Copy code
Exception in thread "DefaultDispatcher-worker-5" java.lang.NullPointerException
	at androidx.compose.ui.node.NodeChain$Differ.insert(NodeChain.kt:445)
	at androidx.compose.ui.node.MyersDiffKt.applyDiff(MyersDiff.kt:122)
	at androidx.compose.ui.node.MyersDiffKt.executeDiff(MyersDiff.kt:135)
	at androidx.compose.ui.node.NodeChain.structuralUpdate(NodeChain.kt:546)
	at androidx.compose.ui.node.NodeChain.updateFrom$ui(NodeChain.kt:204)
	at androidx.compose.ui.node.LayoutNode.applyModifier(LayoutNode.kt:950)
	at androidx.compose.ui.node.LayoutNode.setModifier(LayoutNode.kt:939)
	at androidx.compose.ui.node.ComposeUiNode$Companion.SetModifier$lambda$1(ComposeUiNode.kt:41)
	at androidx.compose.runtime.Applier.apply(Applier.kt:180)
	at androidx.compose.runtime.changelist.Operation$UpdateNode.execute(Operation.kt:551)
	at androidx.compose.runtime.changelist.Operations.executeAndFlushAllPendingOperations(Operations.kt:349)
	at androidx.compose.runtime.changelist.ChangeList.executeAndFlushAllPendingChanges(ChangeList.kt:88)
	at androidx.compose.runtime.CompositionImpl.applyChangesInLocked(Composition.kt:1036)
	at androidx.compose.runtime.CompositionImpl.applyChanges(Composition.kt:1067)
	at androidx.compose.runtime.Recomposer$runRecomposeAndApplyChanges$2.invokeSuspend$lambda$21(Recomposer.kt:684)
	at androidx.compose.runtime.BroadcastFrameClock$FrameAwaiter.resume(BroadcastFrameClock.kt:43)
	at androidx.compose.runtime.BroadcastFrameClock.sendFrame(BroadcastFrameClock.kt:75)
	at androidx.compose.ui.scene.BaseComposeScene.render(BaseComposeScene.skiko.kt:174)
	at androidx.compose.ui.ImageComposeScene.render(ImageComposeScene.skiko.kt:229)
	at com.louiscad.playground.compose.videogen.lib.ComposeToVideoKt$images$1.invokeSuspend(ComposeToVideo.kt:117)
Yup, last line is leaking the project topic
s
Ooooooh that sounds like a cool project!!!
l
Having the issue even with
--no-build-cache --no-configuration-cache --rerun-tasks
Here's the link to the commit where I have the issue. https://github.com/LouisCAD/ComposeVideoGenPlayground/tree/112d0ab8d547e6d86e762a6a3b5c423a6507c926 To use it, run the
composeApp
module, drag'N'drop an empty directory to the gray square. It should generate frames and record them as webp in the given dir (showing the count), then generate a transparent video from those webps named
output.mov
that should contain a counter going from 00 to 09. If you want to try again, drag another empty dir, or delete
output.mov
and drag the same dir.
thank you color 1
🔥 1
It seems that
ImageScene
doesn't like its
use { }
, I mean, its
close()
function to be called too quickly after having been instantiated. Still testing…
When I first tested this code, I was generationg 1080p @60fps videos. Now, I generate a fraction of the resolution (since it's a small overlay to be put on a bigger video in a video editing software, and somehow, I get the issue. I'm added an artificial
delay(5.seconds)
at the last line of the
use { ... }
block, and I have yet to see the issue.
First bad thing,
ImageSceneCompose.close()
isn't idempotent:
Copy code
java.lang.IllegalStateException: ComposeScene is already closed
	at androidx.compose.ui.scene.CanvasLayersComposeSceneImpl.close(CanvasLayersComposeScene.skiko.kt:190)
	at androidx.compose.ui.ImageComposeScene.close(ImageComposeScene.skiko.kt:178)
	at com.louiscad.playground.compose.videogen.lib.ComposeToVideoKt.recordComposableAsVideo-3KjBteM(ComposeToVideo.kt:260)
	at com.louiscad.playground.compose.videogen.lib.ComposeToVideoKt$recordComposableAsVideo$1.invokeSuspend(ComposeToVideo.kt)