3

About

I have an android application, which has 2 activities. Activity A spawns Activity B, and Activity B accesses Room Database in another module. I'm using Koin for all dependency injections, and rxandroid (Schedulers.io() for observing and UI thread for observing) to observe the database transaction

The Issue

When I access the database, the action completes successfully, an entry is added in the database, and then 1-2 seconds later the activity crashes and the app returns to Activity A with no stack trace or any error message in the application logcat.

Im testing the app in AVD Pixel 2 API 28

If I remove all filters from logcat, I can find this error:

2021-01-14 22:31:01.836 9799-9799/com.example.myapp I/System.out: Saving Course
2021-01-14 22:31:01.928 9799-9799/com.example.myapp I/System.out: Added course to DB: 11
2021-01-14 22:31:02.822 9799-9835/com.example.myapp I/om.example.myap: Explicit concurrent copying GC freed 94987(4MB) AllocSpace objects, 0(0B) LOS objects, 49% free, 3MB/6MB, paused 329us total 10.624ms
2021-01-14 22:31:03.439 1935-2006/? W/InputDispatcher: channel '7a68875 com.example.myapp/com.example.myapp.activities.CourseCreatorActivity (server)' ~ Consumer closed input channel or an error occurred.  events=0x9
2021-01-14 22:31:03.439 1935-2006/? E/InputDispatcher: channel '7a68875 com.example.myapp/com.example.myapp.activities.CourseCreatorActivity (server)' ~ Channel is unrecoverably broken and will be disposed!
2021-01-14 22:31:03.441 1935-2006/? W/InputDispatcher: channel '1c99176 com.example.myapp/com.example.myapp.activities.MainActivity (server)' ~ Consumer closed input channel or an error occurred.  events=0x9
2021-01-14 22:31:03.441 1935-2006/? E/InputDispatcher: channel '1c99176 com.example.myapp/com.example.myapp.activities.MainActivity (server)' ~ Channel is unrecoverably broken and will be disposed!
2021-01-14 22:31:03.443 1773-1773/? I/Zygote: Process 9799 exited due to signal (11)

signal 11 is apparently segmentation fault..

What I've tried

  1. Only creating the room entity without inserting it in to the DB still produces the crash
  2. removing Activity A and starting the app on Activity B (which accesses the DB) seems to not produce error (ive tried a few dozen times)
  3. stepping through the save function using the debugger. I can break the main thread or the IO thread, and in both cases the app will crash despite the thread being in break state.
  4. replacing rxandroid for kotlin coroutines. The crash still happens after this
  5. I've tried debugging the app on my phone (pixel 3a) and have so far been unable to reproduce the crash. Will keep trying though.
  6. I tried this on a Pixel 3a AVD at API 30, and couldnt replicate the crash. Then I tried on a Pixel 3a AVD at API 28, and the crash was there. So currently it seems to only happen in API 28...
  7. Tested with API 27 and API 29, both worked fine. Deleted the API 28 SDK and redownloaded it, deleted all related AVDs and recreated them, still getting the signal 11 crash like 2nd try on a fresh install of API 28.. So it seems that the segmentation fault only occurs on Android Pie
  8. I started creating a simplified version of the same overall architecture and logic im using here in an effort to pinpoint where the error originates from exactly. Im not very keen on starting over on the simplified project as without knowing what is causing this error, I would most likely just run in to it again eventually.

Note: Sometimes I will make a change and it will "fix" the issue, only for it to reappear after a while and that makes this really hard to debug with conventional methods

Conclusion

What I really need is some way to debug this. I have no idea what is causing it, and really no idea how to go forward in debugging it.

Olli
  • 375
  • 5
  • 15
  • Very well-formatted question! This smells like a race condition of some sort. Especially with regards to your 2nd point of what you have tried (removing Activity A), I would suggest the following for testing: In the Android Developer Options in the "Apps" section you find the option to always and immediately kill Activities as soon as they are not in foreground anymore. Try to enable this option and see if you can reproduce the bug more consistently. Do not forget to disable it afterwards!! – muetzenflo Jan 18 '21 at 22:01
  • Hi, thanks for the reply! I tried this option and it still crashes instantly, and then "returns" to Activity A. I say "returns" because I guess Activity A should be killed when Activity B opens, but im guessing android studio just starts it up again once it crashes. – Olli Jan 19 '21 at 19:09
  • Jepp, this was meant mainly as approach to narrow down the source of the error. Let's move on: What about the message of the garbace collector (GC)? Is it possible that either `CourseCreatorActivity` or `MainActivity` are allocating a large amount of objects/memory? Is the GC message always part of the error messages? Is it possible for you to paste a bit of code of the two Activities? – muetzenflo Jan 19 '21 at 19:54
  • 1
    `MainActivity` has only a single button which launches `CourseCreatorActivity` intent, and `CourseCreatorActivity` does not allocate significant amounts of data (we're talking like 1-2 dozen very small classes at most. The room database is also very small, or empty in most of my tests. – Olli Jan 20 '21 at 15:50
  • 1
    The GC message spawns regularly, and does not seem to correlate with a crash. `CourseCreatorActivity` has a list of objects, the amount of which the user can change. If the amount of objects is reduced, the objects are removed from the list, at which point GC collects them and spawns the message, which is what happened in that error log i posted in the OP. I cant really share source code for this, but I am trying to recreate the bug in an example project which I will be able to share if I manage to reproduce the crash. (no luck yet on that front) – Olli Jan 20 '21 at 15:55
  • alright, then write a comment, once you created that demo project and I will try to help there. By now I am pretty sure it's a rubber duck problem :) – muetzenflo Jan 20 '21 at 22:58
  • Been doing more testing now, but not gotten any closer. I've basically recreated my original project in its entirety without managing to recreate the crash. One discovery i've made is that invalidating caches and restarting seems to make the crash go away for a long time. I've done it twice now, the first time the crash disappeared for almost a full day. Once it reappeared, I invalidated and restarted once again, and have not been able to recreate the crash since then (its been longer than it took for it to reappear the first time). – Olli Jan 22 '21 at 08:08
  • Once the crash appears, i can reproduce it with 100% success just by accessing the DB, but I've done very thorough testing after invalidating, trying to do every possible permutation of data entry over and over in an effort to make the crash reappear, but it does not crash anymore (yet). The first time the crash reappeared after invalidating caches yesterday, I dont recall doing anything out of the ordinary. Just simply adding another bit of test data to the database. – Olli Jan 22 '21 at 08:11
  • That's really a strange behaviour. With "Invalidating and restart" you mean Android Studio or the App? In any case: In the most recent version of AS they introduced the DatabaseInspector. Maybe this is causing an issue...? Just a wild guess. You could try to create a release build and test it while the device is not connected to AS. Or you try out AS only until version 4.0? I'm just thinking outside the box here... – muetzenflo Jan 22 '21 at 09:09
  • It may also help to create an issue or do a search on the official Google Issue Tracker for Room: https://issuetracker.google.com/issues?q=componentid:413107%20status:open – muetzenflo Jan 22 '21 at 09:12
  • I've been using the database inspector and it doesnt seem to force the crash to occur (but it also didnt help to not use it earlier when the crash was still happening) I'll see about creating an official issue if/when the crash returns. – Olli Jan 22 '21 at 10:15
  • Alright, please report back with a link or solution. I am actually curious what's the cause here. On a side note: What I meant was that the new feature "Database Inspector" *itself* may cause troubles. Thus the suggestion to test the app without any connection/usage of it. – muetzenflo Jan 22 '21 at 12:16

2 Answers2

0

I changed to a different android API level and the problem has not resurfaced since

Olli
  • 375
  • 5
  • 15
0

Having to post as an answer due to the character limit

Going to tack onto this as i was experiencing the same thing across two different EMU's - 28 and 30. Two weeks of debugging i came across this. I felt like my app was simple.

Core composed Dagger2 RxJava2, Room, Retrofit, Material etc.

Main Activity A contained 5 set fragments and 3 were liveData. - fine.

Moved to Class B, fine, Getting a list of Objects from DB. - fine

Moved to Class C, crashing from instant - 7 seconds. This was a similar setup, Class C, contained Fragments that observed different LiveData.

No errors, nothing on debug - just the debugger disconnecting, nothing in logcat except like the above. Nothing in tombstone. Just channel closing + I/Zygote: Process xxxx exited due to signal (11)

The app would always fireup the previous activity or the same activity with no database data.

Fired up leakcanry, nothing there, Fired up Google vitals nothing there, fired up Firebase crashlytics and still nothing there. Even fired up Airbrake, still nothing.

Switched to Class D, that was highly similar to class C but skipped Class B, - still crashing.

Switched to Class E, no live data but saved to DB directly, crashing there.

I have performed the usual invalid cache and restart, wipe data on the EMU's...alot more debugging attempts... Fast forward two weeks, and i came upon this and it saved me having to rip Room out.

Solution: I had to create all new EMU's. Now the exact same code is working from Android 23 to 30.

Scott Johnson
  • 707
  • 5
  • 13