[OneUI] [Exynos] Native crashes

[Emulond]

General information:

Android version: 14
OEM: OneUI 6.1
Model name: SM-G988B
Codename: z3s
Root solution: KernelSU
Zygisk solution: ReZygisk
Kernel: 4.19.87-ExtremeKRNL-v4.7
ᅠ ᅠ

Brief description

On Samsung Galaxy S20 Series with OneUI (includes all Exynos SoC 990 based models) applications suffer from systematic and chaotic/unpredictable native crashes. Occurs only in the background, but in seldom situations might happen during the launching.
ᅠ ᅠ

Important notes

1. Which root solution is affected?

• Magisk
• Kitsune
• KernelSU
• aPatch

2. Which Zygisk solution is affected?

• Magisk native
• Kitsune native
• ZygiskNext
• ReZygisk

3. Does it occur without Xposed modules injected?

• Yes.
• No.

4. Conditional combinations

• Occurs with 🟢 LSP enabled & 🟢 Zygisk enabled.
• Occurs with 🔴 LSP disabled & 🟢 Zygisk enabled.
• Occurs with 🔴 LSP disabled & 🔴 Zygisk disabled.

5. OS affected

• OneUI 5.1, Android 13 – stock.
• OneUI 6.1, Android 14 – port¹.
• AOSP/LOS, Android 13/14.

6. Does replacement of the libraries with AOSP ones help?

• Yes.
• No.

7. Does it affect other Snapdragon devices on OneUI?

• Yes.
• No.

8. Does it affect other Exynos devices on OneUI?²

ᅠ ᅠ

9. What apps are affected?

• System apps.
• User apps.

10. Does it affect not-injected apps?

• Yes.³
• No.

11. Does it affect unlaunchable apps?

• Yes.
• No.

12. Does the issue persist across all boot sessions?

• Yes.
• No.

13. When does it happen?

• In idle/doze mode.
• In active mode.

14. Apps in what state does it affect?

• On-screen app.⁴
• Background app.

ᅠ ᅠ

Misc information

It's been happening for approximately 2 years. And it's not anyhow related to the ROM, or any specific root solution, or any specific Zygisk implementation.
It's impossible to manually reproduce the issue, because it only happens by itself and about 14 times a day.
In addition, @DanGLES3 said that, basically, ART libraries are now identical disregard of the OEM due to introduction of universal Google Play System Update APEX distribution.

Example of the described crash

🐞 Native crash: d.app.dressroom

[Device Brand]: samsung
[Device Model]: SM-S988B
[Display]: ExtremeROM v4.6 (UP1A.231005.007.S908BXXSAEXE3)
[Android Version]: 14
[Android API Level]: 34
[System Locale]: ru_RU
[Process ID]: 16650
[User ID]: 0
[CPU ABI]: arm64-v8a
[Package Name]: com.samsung.android.app.dressroom
[Version Name]: 2.6.70.29
[Version Code]: 267029000
[Target SDK]: 34
[Min SDK]: 33
[Error Type]: Native
[Crash Time]: 2024-12-14T01:19:25.053
[Stack Trace]:
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'samsung/b0sxser/b0s:14/UP1A.231005.007/S908BXXSAEXE3:user/release-keys'
Revision: '23'
ABI: 'arm64'
Processor: '0'
Timestamp: 2024-12-14 01:19:24.539918540+0300
Process uptime: 0s
Cmdline: zygote64
pid: 16650, tid: 16665, name: d.app.dressroom  >>> zygote64 <<<
uid: 1000
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x000000735dc211e8
    x0  000000000000000b  x1  000000767fe58da0  x2  000000767fe58e20  x3  0000000000000008
    x4  000000744e754130  x5  0000000000000004  x6  0000000000000a6e  x7  7f7f7f7f7f7f7f7f
    x8  89930b4767bd19fa  x9  89930b4767bd19fa  x10 000000734e862040  x11 0000000000000000
    x12 0000000000000000  x13 0000000000000000  x14 0000000000000031  x15 0000000000000030
    x16 0000007673fcc300  x17 000000765b36f504  x18 000000734b078000  x19 000000767fe58e20
    x20 000000767fe58e20  x21 000000767fe58da0  x22 0000000000000001  x23 0000007673fd1000
    x24 000000734e862000  x25 000000735dc21000  x26 0000007673fd1694  x27 0000007673fd1698
    x28 0000007673fd0408  x29 000000767fe58c90
    lr  0000007673fc706c  sp  000000767fe58b60  pc  000000735d72d3b0  pst 0000000060001000
10 total frames
backtrace:
      #00 pc 000000000052d3b0  /apex/com.android.art/lib64/libart.so (art::FaultManager::HandleSigsegvFault(int, siginfo*, void*)+48) (BuildId: c35c9ebf7bb06435e4b31977d87bd5d5)
      #01 pc 0000000000007068  /apex/com.android.art/lib64/libsigchain.so (art::SignalChain::Handler(int, siginfo*, void*)+368) (BuildId: 1dfc84ea17eda8296164845381922b35)
      #02 pc 00000000000005d8  [vdso] (__kernel_rt_sigreturn+0)
      #03 pc 00000000009b6b30  /apex/com.android.art/lib64/libart.so (BuildId: c35c9ebf7bb06435e4b31977d87bd5d5)
      #04 pc 00000000005dcc88  /apex/com.android.art/lib64/libart.so (art::Thread::Thread(bool)+196) (BuildId: c35c9ebf7bb06435e4b31977d87bd5d5)
      #05 pc 000000000062222c  /apex/com.android.art/lib64/libart.so (art::Thread* art::Thread::Attach<art::Thread::Attach(char const*, bool, _jobject*, bool, bool)::$_0>(char const*, bool, art::Thread::Attach(char const*, bool, _jobject*, bool, bool)::$_0, bool) (.__uniq.112444171608964125319761912539055931073.llvm.17385930779745706793)+160) (BuildId: c35c9ebf7bb06435e4b31977d87bd5d5)
      #06 pc 00000000006760b4  /apex/com.android.art/lib64/libart.so (art::Runtime::AttachCurrentThread(char const*, bool, _jobject*, bool, bool)+132) (BuildId: c35c9ebf7bb06435e4b31977d87bd5d5)
      #07 pc 000000000002b900  /apex/com.android.art/lib64/libperfetto_hprof.so (void* std::__1::__thread_proxy[abi:nn180000]<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, ArtPlugin_Initialize::$_7> >(void*)+116) (BuildId: 9299b6ce82fd6a7f26e3799ece61cd3f)
      #08 pc 00000000000be8c8  /apex/com.android.runtime/lib64/bionic/libc.so (__pthread_start(void*)+208) (BuildId: 7b2771e16ba279a5186fe9e8c815e964)
      #09 pc 000000000005b3b0  /apex/com.android.runtime/lib64/bionic/libc.so (__start_thread+64) (BuildId: 7b2771e16ba279a5186fe9e8c815e964)

ᅠ ᅠ ᅠ ᅠ

---

¹ — ported from S22; somehow the parent device, having just the same firmware, is not affected: this proves once again that the issue is Exynos 990 specific, [but only speaking of OneUI OEM].
² — a final answer is yet to be discovered…
³ — no relevance between injection of a particular app and crashes frequency has been found. In fact, the vast majority of apps crashes are non-injected ones.
⁴ — yes, I have to admit that it can crash during the launching or when running an application, but this happens basically in 0,00001% of situations.

[bocchi810]

Could you try this CI version by me?Since I can't simulate your device environment, it may still be like this

[Emulond]

Could you try this CI version by me?

Hello! Thanks for your assistance. I have installed your fork, the device has booted properly. I will keep you updated.
One of the changes I have noticed, is that I'm once again able to launch the parasitic manager, because previously on the latest Nightly build LSPosed-v1.10.1-7159-zygisk-debug I was having this error:

⚠️ java.io.IOException: apk signature not verified

2024-12-16 15:20:15.136 7246 26439 root E LSPosedService : failed to open manager apk
java.io.IOException: java.io.IOException: apk signature not verified
 at org.lsposed.lspd.util.InstallerVerifier.verifyInstallerSignature(InstallerVerifier.java:28)
 at org.lsposed.lspd.service.ConfigFileManager.getManagerApk(ConfigFileManager.java:162)
 at org.lsposed.lspd.service.ConfigManager.getManagerApk(ConfigManager.java:1078)
 at org.lsposed.lspd.service.LSPApplicationService.requestInjectedManagerBinder(LSPApplicationService.java:157)
 at org.lsposed.lspd.service.ILSPApplicationService$Stub.onTransact(ILSPApplicationService.java:110)
 at org.lsposed.lspd.service.LSPApplicationService.onTransact(LSPApplicationService.java:107)
 at android.os.Binder.execTransactInternal(Unknown Source:94)
 at android.os.Binder.execTransact(Unknown Source:39)
Caused by: java.io.IOException: apk signature not verified
 at org.lsposed.lspd.util.InstallerVerifier.verifyInstallerSignature(InstallerVerifier.java:20)
 ... 7 more

[bocchi810]

@JingMatrix Are you set the apk signature into the github secrets?
Action "Write key" need this

      - name: Write key
        if: ${{ ( github.event_name != 'pull_request' && github.ref == 'refs/heads/master' ) || github.ref_type == 'tag' }}
        run: |
          if [ ! -z "${{ secrets.KEY_STORE }}" ]; then
            echo androidStorePassword='${{ secrets.KEY_STORE_PASSWORD }}' >> gradle.properties
            echo androidKeyAlias='${{ secrets.ALIAS }}' >> gradle.properties
            echo androidKeyPassword='${{ secrets.KEY_PASSWORD }}' >> gradle.properties
            echo androidStoreFile='key.jks' >> gradle.properties
            echo ${{ secrets.KEY_STORE }} | base64 --decode > key.jks
          fi

[JingMatrix]

Ah, I didn't. I should have done that, thanks for reminding me of it!