StackOverflowError in WorkManager on KitKat [129091233]

Fixed

Bug

Status Update

No update yet.

Description

ka...@gmail.com

created issue #1

Mar 22, 2019 02:16PM

Component used: android.arch.work:work-runtime
Version used: 1.0.0-rc01
Devices/Android versions reproduced on: We've seen it on 4.4.4 and 4.4.2

We haven't been able to reproduce this ourselves, but we're seeing it show up in our tracking. There's a StackOverflowError caused somewhere inside WorkManager. Here's the stack trace we get:

Fatal Exception: java.lang.StackOverflowError
at java.util.HashMap.secondaryHash(HashMap.java:350)
at java.util.LinkedHashMap.get(LinkedHashMap.java:251)
at android.util.LruCache.get(LruCache.java:118)
at android.database.sqlite.SQLiteConnection.acquirePreparedStatement(SQLiteConnection.java:1100)
at android.database.sqlite.SQLiteConnection.prepare(SQLiteConnection.java:689)
at android.database.sqlite.SQLiteSession.prepare(SQLiteSession.java:588)
at android.database.sqlite.SQLiteProgram.(SQLiteProgram.java:58)
at android.database.sqlite.SQLiteQuery.(SQLiteQuery.java:37)
at android.database.sqlite.SQLiteDirectCursorDriver.query(SQLiteDirectCursorDriver.java:44)
at android.database.sqlite.SQLiteDatabase.rawQueryWithFactory(SQLiteDatabase.java:1433)
at android.database.sqlite.SQLiteDatabase.rawQueryWithFactory(SQLiteDatabase.java:1408)
at android.arch.persistence.db.framework.FrameworkSQLiteDatabase.query(myapp:161)
at android.arch.persistence.room.RoomDatabase.query(myapp:233)
at androidx.work.impl.model.DependencyDao_Impl.getDependentWorkIds(myapp:117)
at androidx.work.impl.WorkerWrapper.recursivelyFailWorkAndDependents(myapp:503)
<snip ~50 recursive frames>
at androidx.work.impl.WorkerWrapper.recursivelyFailWorkAndDependents(myapp:503)
at androidx.work.impl.WorkerWrapper.setFailedAndResolve(myapp:488)
at androidx.work.impl.WorkerWrapper.runWorker(myapp:242)
at androidx.work.impl.WorkerWrapper.run(myapp:127)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1112)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:587)
at java.lang.Thread.run(Thread.java:841)

#0. Crashed: WorkManager-WorkManagerTaskExecutor-thread-0
at java.util.HashMap.secondaryHash(HashMap.java:350)
at java.util.LinkedHashMap.get(LinkedHashMap.java:251)
at android.util.LruCache.get(LruCache.java:118)
at android.database.sqlite.SQLiteConnection.acquirePreparedStatement(SQLiteConnection.java:1100)
at android.database.sqlite.SQLiteConnection.prepare(SQLiteConnection.java:689)
at android.database.sqlite.SQLiteSession.prepare(SQLiteSession.java:588)
at android.database.sqlite.SQLiteProgram.(SQLiteProgram.java:58)
at android.database.sqlite.SQLiteQuery.(SQLiteQuery.java:37)
at android.database.sqlite.SQLiteDirectCursorDriver.query(SQLiteDirectCursorDriver.java:44)
at android.database.sqlite.SQLiteDatabase.rawQueryWithFactory(SQLiteDatabase.java:1433)
at android.database.sqlite.SQLiteDatabase.rawQueryWithFactory(SQLiteDatabase.java:1408)
at android.arch.persistence.db.framework.FrameworkSQLiteDatabase.query(myapp:161)
at android.arch.persistence.room.RoomDatabase.query(myapp:233)

Comments

su...@google.com <su...@google.com> #2Mar 22, 2019 06:32PM

Hi, thanks for report!

Could you attach a bit more information about the heap at this point (e.g. a heap dump) if the leak is not reproducible in trivial project?

ka...@gmail.com <ka...@gmail.com> #3Mar 22, 2019 07:31PM

Attached!

su...@google.com <su...@google.com> #4Mar 22, 2019 08:25PM

I looked into the heap dump, seems like we are not disposing certain snapshots. Current snapshot id seems to be around 42k, but we have 108, 116 and 14123 in invalid SnapshotIdSet for current global snapshot. It is hard to figure out what caused it without repro though, as those snapshots seem to be already collected by GC.

ka...@gmail.com <ka...@gmail.com> #5Mar 22, 2019 08:40PM

I managed to repro it after a bunch of debugging. The bad news is that it's caused when using Coil within a LazyColumn, so that library is doing something that's causing you to leak snapshots... somehow.

Repro:

Add implementation io.coil-kt:coil-compose:2.1.0 to build.gradle
Add the following composable:

@Composable fun Leak() {
    val lazyListState = rememberLazyListState()
    val items by remember { mutableStateOf(List(10000) { it }) }

    LazyColumn(state = lazyListState) {
        items(items) {
            Box(Modifier.fillMaxWidth()) {
                AsyncImage(
                    model = "https://i.picsum.photos/id/104/200/200.jpg?hmac=3XxEVXVjwoI45-6sum_iMwNZ52GT-SJacVWr4fh4hqI",
                    contentDescription = null
                )
            }
        }
    }
}

Scroll
Memory 📈

[Deleted User] <[Deleted User]> #6Mar 24, 2019 01:23PM

Project: platform/frameworks/support
Branch: androidx-main

commit e82b3518094e5451dd4697f31a412c10075b28c5
Author: Andrei Shikov <ashikov@google.com>
Date: Wed Jul 20 23:43:58 2022

Dispose nested snapshots created from transparent snapshots

Adds a flag to transparent snapshots to "manage" wrapped snapshots which forces dispose of the wrapped snapshot whenever transparent one is disposed.
This flag is only enabled for the snapshots taken inside transparent snapshots, fixing memory leaks in certain conditions.

Fixes a minor bug where transparent snapshot wasn't receiving reads from nested snapshots as well.

Fixes: 239603305
Test: SnapshotTests#testNestedWithinTransparentSnapshotDisposedCorrectly

Change-Id: I62eddd279c8cf44b032d852d646c9ba21ad08a39

M compose/runtime/runtime/src/commonMain/kotlin/androidx/compose/runtime/snapshots/Snapshot.kt
M compose/runtime/runtime/src/commonTest/kotlin/androidx/compose/runtime/snapshots/SnapshotTests.kt

https://android-review.googlesource.com/2160780

su...@google.com <su...@google.com> #7Mar 28, 2019 08:09PM

Marked as fixed, reassigned to su...@google.com.

Thanks for the quick turnaround!

ka...@gmail.com <ka...@gmail.com> #8Mar 28, 2019 08:38PM

The following release(s) address this bug:

androidx.compose.runtime:runtime:1.3.0

su...@google.com <su...@google.com> #9Mar 28, 2019 09:11PM

This will probably be available next week, and so far the plan is to port it to the 1.x branch as well.

That being said, please be aware that all active Jetpack and Support Library development is happening in the AndroidX branches, so I would highly recommend switching your app when you get a chance. Thanks!

ka...@gmail.com <ka...@gmail.com> #10Mar 29, 2019 11:44AM

Thanks for the info. We're definitely planning on moving to AndroidX, but until we do, I appreciate that you're porting fixes to the old version.