[logs] crash

[Ethran]

App Version: 0.2.1 (35)

java.lang.IllegalStateException: Unsupported concurrent change during composition. A state object was modified by composition as well as being modified outside composition.
at androidx.compose.runtime.Recomposer.applyAndCheck(Recomposer.kt:1560)
at androidx.compose.runtime.Recomposer.performRecompose(Recomposer.kt:2094)
at androidx.compose.runtime.Recomposer.access$performRecompose(Recomposer.kt:159)
at androidx.compose.runtime.Recomposer$runRecomposeAndApplyChanges$2.invokeSuspend$lambda$2(Recomposer.kt:638)
at androidx.compose.runtime.Recomposer$runRecomposeAndApplyChanges$2$$ExternalSyntheticLambda0.invoke(D8$$SyntheticClass:0)
at androidx.compose.ui.platform.AndroidUiFrameClock$withFrameNanos$2$callback$1.doFrame(AndroidUiFrameClock.android.kt:39)
at androidx.compose.ui.platform.AndroidUiDispatcher.performFrameDispatch(AndroidUiDispatcher.android.kt:108)
at androidx.compose.ui.platform.AndroidUiDispatcher.access$performFrameDispatch(AndroidUiDispatcher.android.kt:41)
at androidx.compose.ui.platform.AndroidUiDispatcher$dispatchCallback$1.doFrame(AndroidUiDispatcher.android.kt:69)
at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1317)
at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1327)
at android.view.Choreographer.doCallbacks(Choreographer.java:985)
at android.view.Choreographer.doFrame(Choreographer.java:911)
at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:1302)
at android.os.Handler.handleCallback(Handler.java:942)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loopOnce(Looper.java:201)
at android.os.Looper.loop(Looper.java:288)
at android.app.ActivityThread.main(ActivityThread.java:8049)
at java.lang.reflect.Method.invoke(Method.java:-2)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:548)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:942)

[Ethran]

Analysis by AI:

1) Why it happens

The crash Unsupported concurrent change during composition happens because Jetpack Compose state objects are being modified by a background thread at the exact same time the UI thread is reading them to render the screen.

In PageDataManager.kt, you are using Jetpack Compose state objects for data that is updated from background coroutines:

// needs to be observable by UI, for scroll bars
private var pageHigh = mutableStateMapOf<String, Int>()
private var pageScroll = mutableStateMapOf<String, Offset>()

When recomputeHeight or setPageScroll is called from a background thread (e.g., inside dataLoadingScope which uses Dispatchers.Default or Dispatchers.IO), it mutates these maps. If the UI is simultaneously recomposing and reading these maps, Compose throws this IllegalStateException to prevent inconsistent UI states.

2) How to reproduce it

This is a race condition, so it won't happen 100% of the time, but you can increase the chances of reproducing it by:

1. Opening a notebook with many pages or heavy strokes.
2. Rapidly scrolling, zooming, or switching pages (which triggers background data loading, background stroke indexing, and calls recomputeHeight).
3. Doing this while the UI is actively drawing the scrollbars or page bounds (which forces continuous recomposition).

3) How to fix it

The best architectural fix is to keep Jetpack Compose state (mutableStateOf, mutableStateMapOf) completely out of your data layer (PageDataManager) and use Kotlin Coroutines' StateFlow instead, which is safe for concurrent updates.

Change this in PageDataManager:

private val _pageHigh = MutableStateFlow<Map<String, Int>>(emptyMap())
val pageHigh: StateFlow<Map<String, Int>> = _pageHigh.asStateFlow()

fun recomputeHeight(pageId: String): Int {
    synchronized(accessLock) {
        // ...
        val newHeight = max(maxStrokeBottom.toInt(), SCREEN_HEIGHT)
        _pageHigh.update { it + (pageId to newHeight) }
        return newHeight
    }
}

Then, in your Composable UI, observe it safely:

val pageHeights by pageDataManager.pageHigh.collectAsState()
val height = pageHeights[pageId]

Alternative quick fix: Wrap any mutations to pageHigh and pageScroll in withContext(Dispatchers.Main) { ... } so they are strictly written on the UI thread.

4) Other places in the code that might cause this (if I am wrong)

If the crash isn't coming directly from PageDataManager, here are other places with the same pattern that could trigger this bug:

• SelectionState.kt: It makes heavy use of var selectedStrokes by mutableStateOf<List<Stroke>?>(null) and similar properties. If EditorControlTower or PageView modifies SelectionState from a background coroutine (e.g., during applySelectionDisplaceAndCommit), it will crash the exact same way.
• ReorderableGridState in ReorderableGridItem.kt: It uses mutableStateOf and mutableStateMapOf for item boundaries. If grid bounds are calculated or modified asynchronously, it could cause this.

[mwichro]

Report by Opus 4.7: Unsupported concurrent change during composition on page change

Root cause (TL;DR): EditorViewModel.changePage calls selectionState.reset() from Dispatchers.IO. SelectionState is built from nine mutableStateOf properties read by composables (SelectorBitmap.kt, EditorView.kt:217, CanvasRefreshManager.kt:84), so the off-thread write trips Compose's snapshot consistency check. The log confirms SelectionState reset runs on TID 12052 (worker), not Main.

Fix: wrap the reset() call in withContext(Dispatchers.Main.immediate) { … }, or make SelectionState.reset() self-marshal to Main. Add a requireMain() debug check on every SelectionState mutator to surface future regressions at the write site rather than at recomposition time.

The report also notes the separately-described QuickNav "stale preview" issue likely shares a thread-safety family with PageView.changePage's IO-thread bitmap swap.

The crash

java.lang.IllegalStateException: Unsupported concurrent change during composition.
A state object was modified by composition as well as being modified outside composition.
    at androidx.compose.runtime.Recomposer.applyAndCheck(Recomposer.kt:1560)
    at androidx.compose.runtime.Recomposer.performRecompose(Recomposer.kt:2094)
    ...

This is the standard Compose snapshot-system error raised when a mutableStateOf /
SnapshotStateList value is written from a non-Main thread while the Recomposer
is in the middle of applying a snapshot. There is no application code in the stack
trace, because Compose itself is the thing that detects the inconsistency at
applyAndCheck time — the offending writer has long since returned.

Where the off-thread write happens

EditorViewModel.kt:610-624

fun changePage(id: String) {
    log.d("Changing page to $id, from $currentPageId")
    viewModelScope.launch(Dispatchers.IO) {            // <-- IO worker
        updateOpenedPage(id)
        // 4. Clean the selection state
        selectionState.reset()                          // <-- writes 9 Compose states
    }
}

SelectionState is a Compose state holder
(SelectionState.kt:47-74):

class SelectionState {
    var firstPageCut by mutableStateOf<List<SimplePointF>?>(null)
    var secondPageCut by mutableStateOf<List<SimplePointF>?>(null)
    var selectedStrokes by mutableStateOf<List<Stroke>?>(null)
    var selectedImages by mutableStateOf<List<Image>?>(null)
    var selectedBitmap by mutableStateOf<Bitmap?>(null)
    var selectionStartOffset by mutableStateOf<IntOffset?>(null)
    var selectionDisplaceOffset by mutableStateOf<IntOffset?>(null)
    var selectionRect by mutableStateOf<Rect?>(null)
    var placementMode by mutableStateOf<PlacementMode?>(null)

    fun reset() {
        log.v("reset")
        selectedStrokes = null
        selectedImages = null
        ...
    }
}

These fields are read from inside @composable functions
(see SelectorBitmap.kt –
selectionState.selectedBitmap, selectionDisplaceOffset, selectionRect,
isResizable() etc., plus viewModel.selectionState.firstPageCut is read in
CanvasRefreshManager.kt:84
and selectionState.isNonEmpty() is read every recomposition in
EditorView.kt:217).

So the same Compose state objects are:

• read by composition on the Main thread, and
• written by selectionState.reset() on Dispatchers.IO.

That is exactly the pattern the Recomposer rejects with “Unsupported concurrent
change during composition.”

Confirmation in the attached log

22:36:55.089 12005-12005 EditorViewModel  Changing page to ca3e572a..., from 22537321...   (Main)
22:36:55.090 12005-12087 EditorViewModel  updateOpenedPage: ca3e572a...                    (IO worker 12087)
22:36:55.099 12005-12052 EditorView       Page changed                                     (IO worker 12052)
22:36:55.099 12005-12052 SelectionState   reset                                            (IO worker 12052)

SelectionState.reset is being executed on TID 12052 (a Default/IO worker),
while composition is happening on TID 12005 (Main). The EditorView "Page changed"
log line appearing on the same worker thread is just the IO continuation of
viewModel.changePage calling back through updateOpenedPage — it confirms the
whole changePage body, including the reset(), runs off-Main.

QuickNav makes this crash easy to reproduce because every scrub end fires
changePage (QuickNavViewModel.kt:150-162),
so the user can replay the race by scrubbing repeatedly.

Reproduction recipe

1. Open a notebook in QuickNav.
2. Scrub the page slider rapidly back and forth so onScrubEnd fires often.
3. Have the toolbar visible (so SelectorBitmap and EditorView are actively
   recomposing on the selection state).
4. Within a handful of scrubs the Recomposer trips on the off-thread write
   inside SelectionState.reset() and the process crashes with the stack above.

To make it deterministic for testing, add a Thread.sleep(50) (or
yield()/delay(20)) inside SelectionState.reset() between the first
and last assignment — that widens the window during which composition can
read a partly-mutated set of fields, which is the exact condition Compose
asserts against.

Suggested fix

Move the snapshot writes back to the Main thread. The simplest, lowest-risk
patch is to switch dispatchers around the reset call inside EditorViewModel.changePage:

fun changePage(id: String) {
    log.d("Changing page to $id, from $currentPageId")
    viewModelScope.launch(Dispatchers.IO) {
        updateOpenedPage(id)
        withContext(Dispatchers.Main.immediate) {
            selectionState.reset()
        }
    }
}

A second, more defensive option is to make SelectionState.reset() itself
guarantee Main-thread execution, e.g. by wrapping the body in
Snapshot.withMutableSnapshot { … } and hopping to Dispatchers.Main.immediate
before the writes. That protects every other call site too — EditorControlTower
and SelectorBitmap already happen to call reset() from the UI / gesture
thread, but encoding the invariant in the class is safer than relying on
callers.

The other two callers should be checked the same way:

• EditorControlTower.kt:198 –
  needs verification that the surrounding scope is Main.
• SelectorBitmap.kt:68 –
  this is inside a Compose gesture lambda, already on Main.

Audit the rest of the IO/Default-dispatched code in EditorViewModel,
PageView.changePage, and CanvasObserverRegistry for any other Compose
state writes (none found in this pass beyond the _toolbarState updates,
which are MutableStateFlow and thread-safe — only mutableStateOf /
SnapshotStateList need this treatment).

Suggested extra logging

Until the fix lands, the following lightweight instrumentation makes future
hits easier to attribute:

1. In SelectionState.reset() log the thread:

   log.v("reset on ${Thread.currentThread().name}")

   Any line that isn’t main is a bug.

2. In EditorViewModel.changePage, log the dispatcher boundary:

   log.d("changePage IO->reset, thread=${Thread.currentThread().name}")

3. Add a debug-only assertion helper used by every public mutator on
   SelectionState:

   private fun requireMain() {
       check(Looper.getMainLooper().isCurrentThread) {
           "SelectionState mutated off Main: ${Thread.currentThread().name}"
       }
   }

   Call it from reset, resizeImages, duplicateSelection,
   applySelectionDisplace, deleteSelection. This converts the rare,
   timing-dependent Recomposer crash into an immediate, attributable
   stack trace at the actual write site.

Note on the QuickNav “stale preview” symptom

The issue description in issue_description.md describes a separate visual
bug (canvas not refreshing to the freshly loaded strokes after a QuickNav
page change). That symptom is not the same as this crash, but the two share
a root cause family: PageView.changePage does a lot of windowedBitmap /
windowedCanvas mutation on Dispatchers.IO
(PageView.kt:213-243)
and emits refreshUiImmediately / forceUpdate from there. The
@Volatile markers protect publication of the new bitmap reference, but the
sequence (assign bitmap → assign canvas → call loadInitialBitmap() which
draws into windowedCanvas → emit refresh) is not atomic with respect to
observers on the Main thread that read page.windowedBitmap in
refreshManager.drawCanvasToView (CanvasRefreshManager.kt:70-108).
Worth fixing in the same pass: do the bitmap swap and the initial draw on
the Main thread (or under an explicit lock), and only then emit the
refresh event. That should also remove a class of races that look like
“refresh requested but old preview persists.”