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

apologies, i meant "navigate(To...)"

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

Yep, it appears that navigateUp() returns true, even when nothing visually changes on the screen. This seems to be caused by popBackStack(), which is always returning true even when popping the root Fragment.

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

Project: platform/frameworks/support
Branch: androidx-master-dev

commit 77f6f126b51ef6c880368ed5b4ac900c7b187165
Author: Ian Lake <ilake@google.com>
Date: Wed Feb 06 10:03:44 2019

Fix popBackStack logic when popping the root destination

popBackStack() and by extension navigateUp() should
only return true if the user was successfully navigated
to a new destination. In cases where the entire stack
was popped, the methods should return false so that
additional logic, such as finishing the activity, can
be employed.

This fixes a regression introduced in

https://issuetracker.google.com/issues/123552990

Test: updated tests
BUG: 123933201
Change-Id: I756481f14b2c7d9b8f401bea05c4dbd16d28f614

M navigation/runtime/src/androidTest/java/androidx/navigation/NavControllerTest.kt
M navigation/runtime/src/main/java/androidx/navigation/NavController.java

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

https://goto.google.com/android-sha1/77f6f126b51ef6c880368ed5b4ac900c7b187165

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

This is fixed and will be available in Navigation 1.0.0-beta02.

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

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

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

Fixed in

https://android-review.googlesource.com/c/platform/frameworks/support/+/932127

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

Thanks for addressing that so quickly. Do you know approximately how long it will take for it to make it into a release? And is it at all possible that this will be incorporated into the non-Android-x version of WorkManager? It's a little frustrating that two days after 1.0.0 was released, it was announced that there would be no more development on the non-Android-x version.

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.