MMKV MMKV Crash

The language of MMKV

Java

The version of MMKV

1.3.1

The platform of MMKV

Android

The installation of MMKV

Maven

What's the issue?

Web get a Crash ( Scudo ERROR: race on chunk header at address 0x ).We are using MMKV in Android, and it is used in a multi-process environment. At the same time, we have created multiple MMKV files, with different usage modes for different files. I would like to know if there is a risk of ANR in this scenario?

What's the log of MMKV when that happened?

pid: 0, tid: 7745 >>> com.transsnet.palmpay <<<

backtrace: #00 pc 0x00000000000534d4 /apex/com.android.runtime/lib64/bionic/libc.so (abort+164) #01 pc 0x00000000000418a8 /apex/com.android.runtime/lib64/bionic/libc.so (scudo::die()+8) #02 pc 0x0000000000042250 /apex/com.android.runtime/lib64/bionic/libc.so (scudo::ScopedErrorReport::~ScopedErrorReport()+32) #03 pc 0x0000000000042410 /apex/com.android.runtime/lib64/bionic/libc.so (scudo::reportHeaderRace(void*)+96) #04 pc 0x0000000000048ea8 /apex/com.android.runtime/lib64/bionic/libc.so (scudo::Allocator<scudo::AndroidConfig, &(scudo_malloc_postinit)>::quarantineOrDeallocateChunk(scudo::Options, void*, scudo::Chunk::UnpackedHeader*, unsigned long)+648) #05 pc 0x00000000000440e4 /apex/com.android.runtime/lib64/bionic/libc.so (scudo::Allocator<scudo::AndroidConfig, &(scudo_malloc_postinit)>::deallocate(void*, scudo::Chunk::Origin, unsigned long, unsigned long)+212) #06 pc 0x0000000000045d5c /data/app/~~aBHsfFqLeZIQc9CXPfA7IA==/com.transsnet.palmpay-YnmNyLMQIkW_oDXFC7NxUg==/lib/arm64/libmmkv.so (BuildId: a71d8dcfa9f4f3813b8cb9e938e9b1c76af7ab16) #07 pc 0x0000000000045d0c /data/app/~~aBHsfFqLeZIQc9CXPfA7IA==/com.transsnet.palmpay-YnmNyLMQIkW_oDXFC7NxUg==/lib/arm64/libmmkv.so (BuildId: a71d8dcfa9f4f3813b8cb9e938e9b1c76af7ab16) #08 pc 0x0000000000045c90 /data/app/~~aBHsfFqLeZIQc9CXPfA7IA==/com.transsnet.palmpay-YnmNyLMQIkW_oDXFC7NxUg==/lib/arm64/libmmkv.so (BuildId: a71d8dcfa9f4f3813b8cb9e938e9b1c76af7ab16) #09 pc 0x0000000000045c34 /data/app/~~aBHsfFqLeZIQc9CXPfA7IA==/com.transsnet.palmpay-YnmNyLMQIkW_oDXFC7NxUg==/lib/arm64/libmmkv.so (BuildId: a71d8dcfa9f4f3813b8cb9e938e9b1c76af7ab16) #10 pc 0x0000000000047904 /data/app/~~aBHsfFqLeZIQc9CXPfA7IA==/com.transsnet.palmpay-YnmNyLMQIkW_oDXFC7NxUg==/lib/arm64/libmmkv.so (BuildId: a71d8dcfa9f4f3813b8cb9e938e9b1c76af7ab16) #11 pc 0x0000000000047798 /data/app/~~aBHsfFqLeZIQc9CXPfA7IA==/com.transsnet.palmpay-YnmNyLMQIkW_oDXFC7NxUg==/lib/arm64/libmmkv.so (BuildId: a71d8dcfa9f4f3813b8cb9e938e9b1c76af7ab16) #12 pc 0x00000000000476e8 /data/app/~~aBHsfFqLeZIQc9CXPfA7IA==/com.transsnet.palmpay-YnmNyLMQIkW_oDXFC7NxUg==/lib/arm64/libmmkv.so (BuildId: a71d8dcfa9f4f3813b8cb9e938e9b1c76af7ab16) #13 pc 0x0000000000041140 /data/app/~~aBHsfFqLeZIQc9CXPfA7IA==/com.transsnet.palmpay-YnmNyLMQIkW_oDXFC7NxUg==/lib/arm64/libmmkv.so (BuildId: a71d8dcfa9f4f3813b8cb9e938e9b1c76af7ab16) #14 pc 0x000000000004216c /data/app/~~aBHsfFqLeZIQc9CXPfA7IA==/com.transsnet.palmpay-YnmNyLMQIkW_oDXFC7NxUg==/lib/arm64/libmmkv.so (BuildId: a71d8dcfa9f4f3813b8cb9e938e9b1c76af7ab16) #15 pc 0x00000000001c0594 /data/app/~~aBHsfFqLeZIQc9CXPfA7IA==/com.transsnet.palmpay-YnmNyLMQIkW_oDXFC7NxUg==/oat/arm64/base.odex (art_jni_trampoline+148) #16 pc 0x00000000005c9ef4 /data/app/~~aBHsfFqLeZIQc9CXPfA7IA==/com.transsnet.palmpay-YnmNyLMQIkW_oDXFC7NxUg==/oat/arm64/base.odex (com.tencent.mmkv.MMKV.m+756) #17 pc 0x00000000005b9798 /apex/com.android.art/lib64/libart.so (nterp_helper+152) #18 pc 0x000000000037b1ac /data/app/~~aBHsfFqLeZIQc9CXPfA7IA==/com.transsnet.palmpay-YnmNyLMQIkW_oDXFC7NxUg==/oat/arm64/base.vdex (com.transsnet.palmpay.core.init.PalmPayRemoteConfigInitTask$getTask$1.run+324) #19 pc 0x000000000038d02c /data/app/~~aBHsfFqLeZIQc9CXPfA7IA==/com.transsnet.palmpay-YnmNyLMQIkW_oDXFC7NxUg==/oat/arm64/base.odex (com.alibaba.android.alpha.Task$a.run+172) #20 pc 0x000000000063fd2c /data/misc/apexdata/com.android.art/dalvik-cache/arm64/boot.oat (java.util.concurrent.ThreadPoolExecutor.runWorker+796) #21 pc 0x000000000063ce50 /data/misc/apexdata/com.android.art/dalvik-cache/arm64/boot.oat (java.util.concurrent.ThreadPoolExecutor$Worker.run+64) #22 pc 0x00000000004ebd08 /data/misc/apexdata/com.android.art/dalvik-cache/arm64/boot.oat (java.lang.Thread.run+72) #23 pc 0x000000000033eda4 /apex/com.android.art/lib64/libart.so (art_quick_invoke_stub+612) #24 pc 0x0000000000239d54 /apex/com.android.art/lib64/libart.so (art::ArtMethod::Invoke(art::Thread*, unsigned int*, unsigned int, art::JValue*, char const*)+144) #25 pc 0x000000000053a1b0 /apex/com.android.art/lib64/libart.so (art::Thread::CreateCallback(void*)+1600) #26 pc 0x00000000000c1b40 /apex/com.android.runtime/lib64/bionic/libc.so (__pthread_start(void*)+224) #27 pc 0x0000000000054f20 /apex/com.android.runtime/lib64/bionic/libc.so (__start_thread+64)

MMVK symbolize stack traces: /Users/lingol/Library/Android/sdk/ndk/25.0.8775105/toolchains/llvm/prebuilt/darwin-x86_64/sysroot/usr/include/c++/v1/new:334 /Users/lingol/Library/Android/sdk/ndk/25.0.8775105/toolchains/llvm/prebuilt/darwin-x86_64/sysroot/usr/include/c++/v1/new:292 /Users/lingol/Library/Android/sdk/ndk/25.0.8775105/toolchains/llvm/prebuilt/darwin-x86_64/sysroot/usr/include/c++/v1/new:268 /Users/lingol/Library/Android/sdk/ndk/25.0.8775105/toolchains/llvm/prebuilt/darwin-x86_64/sysroot/usr/include/c++/v1/new:340 /Users/lingol/Library/Android/sdk/ndk/25.0.8775105/toolchains/llvm/prebuilt/darwin-x86_64/sysroot/usr/include/c++/v1/memory:1909 /Users/lingol/Library/Android/sdk/ndk/25.0.8775105/toolchains/llvm/prebuilt/darwin-x86_64/sysroot/usr/include/c++/v1/memory:1599 /Users/lingol/Library/Android/sdk/ndk/25.0.8775105/toolchains/llvm/prebuilt/darwin-x86_64/sysroot/usr/include/c++/v1/string:2379 /Users/lingol/Library/Android/sdk/ndk/25.0.8775105/toolchains/llvm/prebuilt/darwin-x86_64/sysroot/usr/include/c++/v1/string:2400 /Users/lingol/Developer/mmkv/Android/MMKV/mmkv/src/main/cpp/native-bridge.cpp:162

Jan 23 '24 06:01 Zenfer-For-You

The call stacks you symbolized look wrong.

Jan 24 '24 02:01 lingol

I downloaded the mmkv-1.3.1-so-symbols.jar from the Maven Central, and according to the path in the log /lib/arm64/libmmkv.so, I located the arm64-v8a directory. Then I used the addr2line tool to parse out the symbolized stack traces. Is there anything wrong with this approach?

Jan 24 '24 02:01 Zenfer-For-You

I apologize for the confusion, it's a crash, not an ANR. Also, the reported issue is "Scudo ERROR: race on chunk header at address 0x".

Jan 24 '24 08:01 Zenfer-For-You

If that's true, there's nothing we can do about it because it's inside lib stl.

Jan 24 '24 11:01 lingol

Scudo ERROR

#1019

从历史issue列表中找到一个类似的issue，当时的备注是“不是MMKV的问题，最后发现是自己的库多进程初始化时存在的问题” 我们的项目中确实使用了多进程，也是按照文档使用，关于多进程使用有什么建议吗？目前只针对跨进程使用的mmkv实例设置了multi process 模式，其他实例还是single模式。是否需要全部切换到multi process模式？

Jan 26 '24 01:01 shenglinW

是否需要全部切换到multi process模式？

No.

Jan 26 '24 02:01 lingol

@lingol We have reproduced the crash by following code. Is it safe to call MMKV.initialize multiple times? We have checked the code, and it calls MMKV.initialize in different libraries. Is there any way to check the MMKV initialization state?

private fun runMMKVTest() {
    for (i in 0..1000) {
        Thread {
            MMKV.initialize(this, MMKVLogLevel.LevelDebug)
            val current = "test$i"
            val kv = MMKV.mmkvWithID(current)
            kv.encode("bool", true)
            kv.encode("bool"+System.currentTimeMillis(), "hope it works")
            Log.d("TAG", "runMMKvTest: ${Thread.currentThread().name} ${kv.decodeBool("bool")}")

            Thread.sleep(2000)

            val kv2 = MMKV.mmkvWithID(current)

            Log.d("TAG", "runMMKvTest: ${Thread.currentThread().name} ${kv2.decodeBool("bool")}")
        }.start()
    }
}

Feb 22 '24 12:02 shenglinW

You should never call MMKV.initialize() more than once, period.

Feb 26 '24 04:02 lingol

Is there any way to check the MMKV initialization state?

No such thing. You are on your own.

Feb 26 '24 04:02 lingol

Is there any way to check the MMKV initialization state?

No such thing. You are on your own.

you should condsier initialization state

Mar 04 '24 07:03 quibbler01

Is there any way to check the MMKV initialization state?

No such thing. You are on your own.

you should condsier initialization state

No. It only brings more trouble to a already trouble situation.

Mar 04 '24 08:03 lingol