Repository navigation
Seemingly random 'process crashed' for the instrumentation runner #352
Description
Description
What appears to randomly process crashes of the test runner. I understand this may not be the best example on how to present the issue (without the full code), but I was unable to reproduce this on a fresh project :(
Steps to Reproduce
In our app, the test is really simple. When I run it from the IDE it runs almost 100% correctly, from command line via
./gradlew connectedProductionDebugAndroidTest -i
it often fails with the error provided below.
class MyTest {
private val mockViewModel = mockk<FeedViewModel>(relaxed = true, relaxUnitFun = true)
@get:Rule
val mockInjectionRule = MockInjectionRule {
every { it.myViewModel() } returns mockViewModel
every { mockViewModel.shouldDoSomething() } returns false
}
@Test
fun myFragment_titleDisplays() {
launchFragmentInContainer(themeResId = R.style.AppTheme) { MyFragment() }
onView(withText(R.string.title))
.check(ViewAssertions.matches(isDisplayed()))
.check(matches(withParent(withId(R.id.toolbar))))
onView(withId(R.id.action_settings))
.check(matches(isDisplayed()))
}
}
Expected Results
Tests run/pass
Actual Results
Tests pass on average 7/10 times, when they fail, this is logged in Logcat
ActivityManager I Start proc 23437:com.android.chrome:sandboxed_process0/u0i50 for webview_service Ïd
ebug/org.chromium.content.app.SandboxedProcessService0
W Slow operation: 57ms so far, now at startProcess: starting to update pids map
W Slow operation: 57ms so far, now at startProcess: done updating pids map
dboxed_process W Unexpected CPU variant for X86 using defaults: x86
ercentral.debu I Background concurrent copying GC freed 161195(5MB) AllocSpace objects, 5(88KB) LOS objects, 36% free, 10MB/1
6MB, paused 1.468ms total 178.354ms
ActivityManager W Slow operation: 70ms so far, now at attachApplicationLocked: after mServices.attachApplicationLocked
cr_ChildProcessService I Creating new ChildProcessService pid=23437
ActivityManager I Process com.examplepackage.debug (pid 23395) has died: fore TOP
Zygote I Process 23395 exited due to signal (11)
InputDispatcher W channel '81514ff com.examplepackage.debug/androidx.fragment.app.testing.FragmentScenario$EmptyFragmen
tActivity (server)' ~ Consumer closed input channel or an error occurred. events=0x9
E channel '81514ff com.examplepackage.debug/androidx.fragment.app.testing.FragmentScenario$EmptyFragmen
tActivity (server)' ~ Channel is unrecoverably broken and will be disposed!
libprocessgroup W kill(-23395, 9) failed: No such process
I Successfully killed process cgroup uid 10097 pid 23395 in 4ms
cr_ChildProcessService I Destroying ChildProcessService pid=23437
WindowManager I WIN DEATH: Window{81514ff u0 com.examplepackage.debug/androidx.fragment.app.testing.FragmentScenario$
EmptyFragmentActivity}
D HostConnection::get() New Host Connection established 0xe9c0a840, tid 1973
InputDispatcher W Attempted to unregister already unregistered input channel '81514ff com.examplepackage.debug/androidx
.fragment.app.testing.FragmentScenario$EmptyFragmentActivity (server)'
gralloc_ranchu D gralloc_unregister_buffer: exiting HostConnection (is buffer-handling thread)
dboxed_process I System.exit called, status: 0
AndroidRuntime I VM exiting with result code 0, cleanup skipped.
D HostConnection::get() New Host Connection established 0xe9c0a840, tid 1973
gralloc_ranchu D gralloc_unregister_buffer: exiting HostConnection (is buffer-handling thread)
D HostConnection::get() New Host Connection established 0xe9c0a840, tid 1973
gralloc_ranchu D gralloc_unregister_buffer: exiting HostConnection (is buffer-handling thread)
Zygote I Process 23437 exited cleanly (0)
D HostConnection::get() New Host Connection established 0xe9c0a840, tid 1973
GnssLocationProvider I WakeLock acquired by sendMessage(REPORT_SV_STATUS, 0, com.android.server.location.GnssLocationProvider$SvSta
tusInfo@453db8e)
gralloc_ranchu D gralloc_unregister_buffer: exiting HostConnection (is buffer-handling thread)
GnssLocationProvider I WakeLock released by handleMessage(REPORT_SV_STATUS, 0, com.android.server.location.GnssLocationProvider$SvS
tatusInfo@453db8e)
SurfaceFlinger W couldn't log to binary event log: overflow.
ActivityManager W Force removing ActivityRecord{82ebca5 u0 com.examplepackage.debug/androidx.fragment.app.testing.Fragm
entScenario$EmptyFragmentActivity t300}: app died, no saved state
W Crash of app com.examplepackage.debug running instrumentation ComponentInfo{com.examplepackage
.debug.test/com.examplepackage.myapp.CustomTestRunner}
I Force stopping com.examplepackage.debug appid=10097 user=0: finished inst
Process com.android.chrome:sandboxed_process0 (PID: 23437) ended
ActivityManager I Killing 23437:com.android.chrome:sandboxed_process0/u0a97i50 (adj 0): isolated not needed
libprocessgroup W Failed to open process cgroup uid 99050 pid 23437: No such file or directory
--
--
E channel '81514ff com.examplepackage.debug/androidx.fragment.app.testing.FragmentScenario$EmptyFragmen
tActivity (server)' ~ Channel is unrecoverably broken and will be disposed!
libprocessgroup W kill(-23395, 9) failed: No such process
I Successfully killed process cgroup uid 10097 pid 23395 in 4ms
cr_ChildProcessService I Destroying ChildProcessService pid=23437
WindowManager I WIN DEATH: Window{81514ff u0 com.examplepackage.debug/androidx.fragment.app.testing.FragmentScenario$
EmptyFragmentActivity}
AndroidX Test and Android OS Versions
debugImplementation ("androidx.fragment:fragment-testing:1.1.0-alpha08") {
exclude group: "androidx.test", module: "core"
}
androidTestImplementation 'androidx.test.ext:junit:1.1.1-beta01'
androidTestImplementation 'androidx.test:runner:1.1.1'
androidTestImplementation 'androidx.test:rules:1.1.1'
androidTestImplementation 'androidx.test.espresso:espresso-core:3.1.1'
androidTestImplementation 'androidx.test.espresso:espresso-contrib:3.1.1'
androidTestImplementation 'androidx.test.espresso:espresso-web:3.1.1'
androidTestImplementation 'androidx.test.espresso:espresso-intents:3.1.1'
androidTestImplementation "androidx.arch.core:core-testing:2.0.0"
androidTestUtil 'androidx.test:orchestrator:1.1.1'
Emulator is API 28 Nexus 5, animations turned off.
Link to a public git repo demonstrating the problem:
N/A
Reacted by RafaO, ruX, Ashutosh Gangwar, gosr, Jens Driller, NitroG42, Rifqi M Fahmi, Jeffrey How, Kevin Felipe Meneses Palta, André Roggeri Campos and 24 more
Activity
brettchabot commentedon May 17, 2019
Strange. Nothing in the posted stack trace gives me any clue to what might be wrong.
Can you post a sample that reproduces this issue?
tsaulic commentedon May 19, 2019
I'm trying to set up a minimal project where the same issue would occur consistently. Still no luck, but will post an update here if I succeed.
navidRoohi commentedon Aug 6, 2019
Any update about this issue? I m getting
Test instrumentation process crashed., randomly. Adding a bit wait before starting the Test process solved it. but, I don't think is the right way.ruXlab commentedon Oct 18, 2019
Not sure if it can be related but by creating
TestSubscribereven without using it increases chances for process to crash by ~80%, without - ~20%Same as topic starter I use mockk(1.9.3) and
launchFragment(1.2.0)yuriykulikov commentedon Oct 21, 2019
Same here, also mockk 1.9.3 and launchFragment 1.2.0. Running clean before the test seems to solve the issue.
tsaulic commentedon Oct 22, 2019
Thank you @yuriykulikov, mockk 1.9.3 works with 1.2.0-beta02 (as in - the tests run now). Just had to force objenesis version:
But I still get process crashed randomly, unfortunately.
brettchabot commentedon Jan 30, 2020
closing due to lack of info
joreilly commentedon Feb 13, 2020
Also seeing this. Getting random crashes that we've narrowed down to use of mockk. Tried various combinations of versions but still happening
TWiStErRob commentedon Feb 13, 2020
We;re seeing this and the last erroring logcat is suggesting an interplay of Jacoco, Garbage Collector (finalizers) and native. It happens after ~10 minutes of successful test executions. Failure rate is about 3-5%, so not possible to repro.
gosr commentedon Jun 10, 2020
Did anyone find a proper fix for this?
NitroG42 commentedon Jul 23, 2020
Got exactly the same issue with multiple projects. I'm pretty sure this come from mockk from a way or another.
Is there any way to have more info about process crashes when there are absolutly no stack trace in the logcat @brettchabot ?
I'll try to work on a sample because after a few year I can't bear having my CI jobs failing each 1/2 time for no reason 😢
ricard-v commentedon Jul 24, 2020
I have exactly the same issue and I also believe MockK could be behind it. I have posted the issue on SO: https://stackoverflow.com/questions/63059986/android-ui-tests-with-espresso-mockk-crash-with-sigsegv
Looking at OP crash log, I found one common error message:
In my case, this log message is always right before the crash, usually alongside a SIGSEGV.
I am using Espresso to write a login + pwd to test a LoginActivity and I use MockK to mock all the Repositories / Services logic in a MVP architecture.
Also, none of this has happened on my physical devices.
NitroG42 commentedon Jul 24, 2020
I reproduced it on my system: https://github.com/NitroG42/CrashDuringTestSample
I will make another issue.
NitroG42 commentedon Jul 24, 2020
Or can this one with some infos be opened again @brettchabot ?
EDIT: it does seems like the bug is coming from mockk after all but I wonder if there anything that can be done on the testing/emulator part.
4 remaining items
BSuder commentedon Oct 13, 2020
What type of cleaning you mean? Clean cache or clean user data?
kmenesesp commentedon Dec 4, 2020
I am facing exactly the same issue on a project I am working on. Have you found anything?
BSuder commentedon Dec 4, 2020
I have not solve the problem yet, but meybe it hass been caused memmory leaks.
kmenesesp commentedon Dec 4, 2020
Using an x64 emulator solved the problem for me, as cristan commented here: mockk/mockk#466 (comment)
prfarlow1 commentedon Dec 11, 2020
My project uses mockk, and using an x86_64 emulator (API 28+) also solved the problem for me, too mockk/mockk#466 (comment)
mockK 1.10.0 and mockK Android 1.9.3 with objenesis forced at 2.6. I hope the Androidx test team can fix this bug. In Firebase Test Lab, you can't specify the ABI of the emulators used, so it appears basically impossible to run your UI tests in Firebase Test Lab on emulators if you use mockK or mockito
prfarlow1 commentedon Dec 16, 2020
Follow up: I also tried removing mockk as an android test dependency and removed all tests that used it. Once I did that, I found that I could once again run UI tests on non 64 bit emulators
When I do run my tests on a non x86_64 bit emulator using mockk version 1.10.3-jdk8, I notice this log in logcat:
dimgarof commentedon Jan 13, 2021
Using an x86_64 emulator also solved the issue for me.
Anyone knows why is this fix working?
pl9ed commentedon Mar 30, 2021
Did you ever figure out what was causing this / find a workaround? I'm seeing the same exception when running instrumented tests on physical devices.
prfarlow1 commentedon Aug 12, 2021
@ricard-v one year later, any update on this? I'm still stuck on this bug, which prevents me from running any UI tests that use mocking in Firebase Test Lab. Wondering if I just need to bite the bullet and removing all mockking libraries if I want my instrumentation tests to run on FTL virtual devices.
brettchabot commentedon Aug 12, 2021
Sorry for the lack of response on this issue. I wish I could help more but TBH I don't have expertise on mocking libraries . This github project probably isn't the right forum to address this issue, as it doesn't seem to be related to the androidx.test libraries.
Perhaps the mockk/mockito maintainers or Android ART team could be more help?
prfarlow1 commentedon Aug 12, 2021
Apologies, I should have commented in the mockk repository. Here's the corresponding issue mockk/mockk#466
SimonMarquis commentedon Aug 17, 2022
Since this issue is still open, I'll share my minimal reproducible example: https://github.com/SimonMarquis/FTL-segfault
I've also added more details in mockk/mockk#466 (comment)
I hope this will be helpful.
grndvl1 commentedon Jul 25, 2025
Still open and still happening 3 yrs later. Wish that when it crashes it spits out more info like Heap space...crash report...
brettchabot commentedon Jul 25, 2025
As mentioned in the previous comment I don't think this issue is actionable by the androidx.test maintainers #352 (comment) this does