Application 1.6.0 crashes on startup - MediaTek bug

[openmindculture]

The current android version keeps crashing on startup.
Steps to reproduce: touch the app icon. After showing a splash screen for a few seconds, the app closes without further notice.
Earlier versions of the app did work on the same phone.
Android systems settings report that corona risk detection is active and that the German Corona Warn App is assigned to manage them. Bluetooth and location service is activated.
Error keeps recurring also after restarting the device.

App version: 1.6.0 (updated using google play store on 9 November 2020).
Android version: 7.0 (security patch 1 December 2018) Kernel 3.18.35+jslave@WUH1000074104 #3
Hardware: Huawei Honor JMM-L22
Build JMM-L22C432B136
EMU-Version 5.1.3

Avoid duplicates

• Bug is not mentioned in the FAQ
• Bug is specific for Android only, for general issues / questions that apply to iOS and Android please raise them in the documentation repository
• Bug is not already reported in another issue

Describe the bug

Expected behaviour

Steps to reproduce the issue

Technical details

• Mobile device:
• Android version:

Possible Fix

Additional context

---

Internal Tracking ID: EXPOSUREAPP-3847

[JHKobarg]

Hi, I observed the same behaviour with the 1.6.0 version of the app on both my parent’s HTC Desire 12 (with Android 7.1.1, Kernel 4.4.22+); one device failed to start Friday, the other since today; the App shows the logo/splash screen and then crashes directly; the symptom appears to be identical to the description from #1053 but I tried to execute the countermeasure described there and they are not effective.

The system log begins with

F/libc (339): unable to stat "/proc/self/exe": Permission denied
F/libc (339): Fatal signal 6 (SIGABRT), code -6 in tid 339 (init.lct.bootch)

If you need more information I will try to provide that.

[vaubaehn]

Hi @JHKobarg and @openmindculture ,
your issues are most likely not connected to #1053 (with #642 as the underlying root cause). However, the problem is addressed in PRs #1612 and #1604. Interpreting #1620 , a hotfix v1.6.1 should be available in the Google Play Store soon.

@d4rken : FYI. In case you need more logs, @JHKobarg could probably help out here?

[d4rken]

A system log (logcat) from a few seconds before the app is opened till after it crashes would be very welcome.

For how long does the splash screen stay? If the splash screen stays for ~15 seconds, it would point towards the encryption issue, as the retry mechanism will give up after 15 seconds.

cwa-app-android/Corona-Warn-App/src/main/java/de/rki/coronawarnapp/util/security/EncryptedPreferencesFactory.kt

Line 32 in 5bb2427

RetryMechanism.retryWithBackOff {

cwa-app-android/Corona-Warn-App/src/main/java/de/rki/coronawarnapp/util/RetryMechanism.kt

Line 43 in 5bb2427

private const val DEFAULT_TOTAL_MAX_RETRY = 15 * 1000L // 15 seconds total delay

[openmindculture]

The splash screen only stays for about 2 seconds, sometimes but not always followed by a white screen for another ca. 4 seconds. Is there an easy way to generate an error log directly on my phone, or do I have to connect to a pc running adb to do so? I can try to provide an error log tomorrow. Am 16. November 2020 22:00:13 MEZ schrieb Matthias Urhahn <notifications@github.com>:

…

A system log (logcat) from a few seconds before the app is opened till after it crashes would be very welcome. For how long does the splash screen stay? If the splash screen stays for ~15 seconds, it would point towards the encryption issue, as the retry mechanism will give up after 15 seconds. https://github.com/corona-warn-app/cwa-app-android/blob/5bb2427e5671c681d6aad0d53c6a4772855abcb3/Corona-Warn-App/src/main/java/de/rki/coronawarnapp/util/security/EncryptedPreferencesFactory.kt#L32 https://github.com/corona-warn-app/cwa-app-android/blob/5bb2427e5671c681d6aad0d53c6a4772855abcb3/Corona-Warn-App/src/main/java/de/rki/coronawarnapp/util/RetryMechanism.kt#L43 -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #1609 (comment)

[d4rken]

ADB would let you pull only that specific log section.

You can also catch a log via "bugreport" on the device itself.

Note that the bug report may contain sensitive information such as your phone number or log output from other installed apps. I'd recommend to not post that publicly, but you could share (email/cloud) that directly with me if that is okay for you (matthias.urhahn@sap.com).

[openmindculture]

logcat.log

Here is a logfile around a cwa crash.
As the log mentions "not enough space" on my device, I will retry to reproduce the crash after freeing up some space.

[openmindculture]

Freed up memory, force stopped cwa app, restarted the phone, then launched cwa again. Same bug keeps ocurring.

[d4rken]

Awesome thanks for the log, so this is the stacktrace:

11-17 12:23:03.635 29303 29328 E AndroidRuntime: Process: de.rki.coronawarnapp, PID: 29303
11-17 12:23:03.635 29303 29328 E AndroidRuntime: java.lang.ClassCastException: kotlinx.coroutines.channels.ProducerCoroutine cannot be cast to kotlin.jvm.functions.Function2
11-17 12:23:03.635 29303 29328 E AndroidRuntime: 	at kotlin.coroutines.intrinsics.IntrinsicsKt__IntrinsicsJvmKt$createCoroutineUnintercepted$$inlined$createCoroutineFromSuspendFunction$IntrinsicsKt__IntrinsicsJvmKt$4.invokeSuspend(IntrinsicsJvm.kt:7)
11-17 12:23:03.635 29303 29328 E AndroidRuntime: 	at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:3)
11-17 12:23:03.635 29303 29328 E AndroidRuntime: 	at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:15)
11-17 12:23:03.635 29303 29328 E AndroidRuntime: 	at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:1)
11-17 12:23:03.635 29303 29328 E AndroidRuntime: 	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:13)
11-17 12:23:03.635 29303 29328 E AndroidRuntime: 	Suppressed: java.lang.ClassCastException: kotlinx.coroutines.channels.ProducerCoroutine cannot be cast to kotlin.jvm.functions.Function2
11-17 12:23:03.635 29303 29328 E AndroidRuntime: 		... 5 more

Seems to be this:

• RendezvousChannel cannot be cast to Function2 Kotlin/kotlinx.coroutines#1989
• https://issuetracker.google.com/issues/140347159

That's a tough cookie ☹️
According to b/140347159 on Google's bug tracker it's a bug in the VM of your ROM. Where the code of our app is just right to trigger it.

I can find similar stacktraces for other devices, all with Android 7.0-7.1, and all with Mediatek Chipsets.

Will analyze this further to see what would be the best way forward.
Some thoughts:

• This could be fixed by any update if we are lucky enough that the code is just compiled different enough to not hit that VM bug.
• Could adjust the proguard config so that R8 shrinks the code differently so that we no longer hit this. Difficult to see which code to target as the stacktrace is unspecific 🤔

[vaubaehn]

@d4rken this looks like bad news in general, as the bug could occur anytime when the triggering byte code is compiled by chance in future updates... And even Google can fix this issue in a timely manner, will the vendors provide updates for their old devices? (Or is this something that can go through Google Play Services?)

Is there any Huawei Honor JMM-L22 with Android 7 in the Telekom test farm as a test device? If not, then it's maybe time to add one...

[vaubaehn]

@JHKobarg as you are also on Android 7, and your HTC Desire 12 also owns a MediTek chipset, there is a large likelihood, that you're also experiencing the VM Bug.
@openmindculture and @JHKobarg , CWA 1.6.1 just released in Play Store in these minutes. The fixes of that hotfix release are not adressing your problem here. But it would be wonderful if you updated, and report back, if by chance the crash is gone for you (in other words, the byte code change was already good enough).
Thanks a lot!

[d4rken]

will the vendors provide updates for their old devices?

I wouldn't get my hopes up. Devices withMediaTek chipsets are unfortunately notorious for this, few updates and ROM specific bugs 😦.

(Or is this something that can go through Google Play Services?)

The fix would have to come as OTA from the device manufacturer.

[vaubaehn]

Irgendwas ist ja immer. 🙁
(didn't know how to express in English)

[vaubaehn]

@d4rken but to have a positive perspective on that issue:
Until now, at least the VM bug was not affecting CWA. And maybe after any arbitrary update, it won't occur again.
Let's keep fingers crossed.

[vaubaehn]

@d4rken one idea: did I see right, that devs put some APKs to the tracked google issue? If it's a specific byte code that triggers the crash, wouldn't it be possible to compare the compilations on binary level, and to search for similar patterns? If the triggering pattern could be identified, then at least after CWA compilation the compiled code could be scanned to be free of the trigger. Worth investigating?

[vaubaehn]

@d4rken another approach could be to build yourself using Kotlin/kotlinx.coroutines#1648 (comment) - this seems to fix/workaround/mitigate it. Not sure if it's possible and worth the effort.

[d4rken]

@d4rken one idea: did I see right, that devs put some APKs to the tracked google issue? If it's a specific byte code that triggers the crash, wouldn't it be possible to compare the compilations on binary level, and to search for similar patterns? If the triggering pattern could be identified, then at least after CWA compilation the compiled code could be scanned to be free of the trigger. Worth investigating?

Maybe, but I'm not sure if it's an effective approach. Each update contains so many changes, and we don't have a locally reproduced case, finding the byte code that causes this could take weeks if not month. But even if we had a device where we could reproduce it locally. Once found it's not guaranteed that there is a fix available that would help all affected devices, it may be that each device needs it's own specific variant of a fix.

@d4rken another approach could be to build yourself using Kotlin/kotlinx.coroutines#1648 (comment) - this seems to fix/workaround/mitigate it. Not sure if it's possible and worth the effort.

That looks interesting and will be looked into.

[vaubaehn]

Maybe, but I'm not sure if it's an effective approach. Each update contains so many changes, and we don't have a locally reproduced case, finding the byte code that causes this could take weeks if not month. But even if we had a device where we could reproduce it locally. Once found it's not guaranteed that there is a fix available that would help all affected devices, it may be that each device needs it's own specific variant of a fix.

I was assuming, there may be only one specific byte code that triggers the crash for all apps that contain that specific byte code (on Android 7 devices with MediaTek chipset). When comparing different apps (of different producers) experiencing the crash, maybe that triggering byte code could be identified. If you then know that code, in the end, you could check if your own compiled code contains that specific pattern that causes the crash.
If yes,

• This could be fixed by any update if we are lucky enough that the code is just compiled different enough to not hit that VM bug.

• Could adjust the proguard config so that R8 shrinks the code differently so that we no longer hit this. Difficult to see which code to target as the stacktrace is unspecific thinking

If no, do nothing.
So, if my assumptions would be right, that'll just be workaround, not a fix.

That looks interesting and will be looked into.

If this looks promising for you, then this is actually the best way.

I'm off for the time - have a nice evening and rest of the week!

[dsarkar]

Dear community,

In order to be more specific regarding the previous post #1609 (comment): There are several PRs that possibly mitigate the issue, but not necessarily fixes this problem for all users.

We would appreciate feedback regarding this issue after the rollout of releases 1.8 or 1.9.

Thank you for your understanding. Best wishes, DS

---

Corona-Warn-App Open Source Team

[ghost]

I've tested the 1.8 Eval, and it seems to be fine for me. (Hardware: Huawei Honor JMM-L22, Build JMM-L22C432B136, EMU-Version 5.1.3, Android 7.0)

@thomasaugsten asked me to start testing the 1.9 Eval - I started with that today.

CC: @dsarkar

[dsarkar]

@Yanabamenara, thanks for letting us know! DS

[jmw168]

I have the same Problem with Android 7 and the cwa 1.7.1 on a Moto C Plus. The app works in the background but crashes whenever I try to open the user interface. If anyony could tell me, where I find the apk-links to the eval version, I would test if the updates work for me.

[dsarkar]

Hi @jmw168,

Thanks for reporting. see #1609 (comment).

Best wishes, DS

---

Corona-Warn-App Open Source Team

[HilRick5]

Hi @dsarkar , @d4rken ,
just received the app update. cwa 1.9.1 solved the issue on my Cubot Kingkong running with Android 1.7.1
Thanks !
HR

[dsarkar]

Hi@HilRick5. Thanks for the feedback. We will forward this feedback to the developers. Best wishes, DS

---

Corona-Warn-App Open Source Team

[dsarkar]

Hi @jmw168, @JHKobarg, @openmindculture, and community,

We would appreciate feedback on this issue. Did CWA 1.9.1 mitigate the problem for you? Thanks. DS

---

Corona-Warn-App Open Source Team

[openmindculture]

Installed CWA 1.9.1 from Google Play Store yesterday and have been keeping the charger on all night for about 11 hours now. Restarted the phone this morning. The app is still working fine. The error did not occur again until now.

[dsarkar]

@openmindculture, thanks for the feedback, will forward the info to devs. DS

[Batterypack200]

I can confirm that version 1.9.1 doesn't seem to have the bug anymore. I also charged overnight and so far there has been no more crash.
Moto E4

[jmw168]

I installed version 1.9.1 yesterday and till now there was no crash.

[dsarkar]

@jmw168, @Batterypack200, thanks for the feedback, will forward the info to devs. DS

[heinezen]

No further negative reports on this. The bug seems to be fixed for everyone who upgraded to 1.9. We'll close the isse then.

---

Corona-Warn-App Open Source Team