Android libicuuc.so (utext_close) 中的神秘崩潰

Question

在最新更新后，我們的 Android 游戲開始在 Google Play ANR 和崩潰部分記錄奇怪的崩潰。

backtrace:
  #00  pc 000000000011be50  /system/lib64/libicuuc.so (utext_close_60+52)
  #01  pc 00000000001aa4c4  /system/lib64/libicui18n.so (icu_60::RegexPattern::zap()+212)
  #02  pc 00000000001aa560  /system/lib64/libicui18n.so (icu_60::RegexPattern::~RegexPattern()+36)
  #03  pc 0000000000094120  /system/framework/arm64/boot-core-libart.oat (offset 0x90000) (java.math.NativeBN.BN_copy [DEDUPED]+160)
  #04  pc 000000000018340c  /system/framework/arm64/boot-core-libart.oat (offset 0x90000) (libcore.util.NativeAllocationRegistry$CleanerThunk.run+76)
  #05  pc 000000000040c754  /system/framework/arm64/boot.oat (offset 0x13b000) (sun.misc.Cleaner.clean+164)
  #06  pc 00000000001daa0c  /system/framework/arm64/boot.oat (offset 0x13b000) (java.lang.ref.ReferenceQueue.enqueueLocked+236)
  #07  pc 00000000001dab2c  /system/framework/arm64/boot.oat (offset 0x13b000) (java.lang.ref.ReferenceQueue.enqueuePending+172)
  #08  pc 00000000001d7b04  /system/framework/arm64/boot-core-libart.oat (offset 0x90000) (java.lang.Daemons$ReferenceQueueDaemon.runInternal+244)
  #09  pc 000000000015978c  /system/framework/arm64/boot-core-libart.oat (offset 0x90000) (java.lang.Daemons$Daemon.run+76)
  #10  pc 00000000002c1038  /system/framework/arm64/boot.oat (offset 0x13b000) (java.lang.Thread.run+72)
  #11  pc 000000000056ef88  /system/lib64/libart.so (art_quick_invoke_stub+584)
  #12  pc 00000000000d4204  /system/lib64/libart.so (art::ArtMethod::Invoke(art::Thread*, unsigned int*, unsigned int, art::JValue*, char const*)+200)
  #13  pc 0000000000472fd4  /system/lib64/libart.so (art::(anonymous namespace)::InvokeWithArgArray(art::ScopedObjectAccessAlreadyRunnable const&, art::ArtMethod*, art::(anonymous namespace)::ArgArray*, art::JValue*, char const*)+104)
  #14  pc 0000000000474090  /system/lib64/libart.so (art::InvokeVirtualOrInterfaceWithJValues(art::ScopedObjectAccessAlreadyRunnable const&, _jobject*, _jmethodID*, jvalue*)+424)
  #15  pc 000000000049f684  /system/lib64/libart.so (art::Thread::CreateCallback(void*)+1120)
  #16  pc 0000000000083588  /system/lib64/libc.so (__pthread_start(void*)+36)
  #17  pc 00000000000241dc  /system/lib64/libc.so (__start_thread+68)

更新中唯一與此相關的更改代碼是在我們的分析模塊中，我們正在其中進行一些字符串替換：

private static String formatStringForAnalytics(String str) {
    if(str == null) {
        return "";
    }

    return str.replaceAll(" ", "_").replaceAll(":", "");
}

我們自己無法重現崩潰。 因此，我們必須稍等片刻才能制作並發布新的更新，在該更新中我們禁用這段代碼並查看崩潰是否似乎消失了。

我只是覺得標准字符串替換會導致這樣的事情很奇怪。 其他人遇到過類似的崩潰嗎？

Answer 1

問題實際上是錯誤的字符串替換 function。

API 文檔說replaceAll()方法

用給定的替換替換此字符串中與給定正則表達式匹配的每個 substring。

我將代碼更改為使用replace()方法

用指定的文字替換序列替換此字符串中與文字目標序列匹配的每個 substring。

這實際上是代碼最初打算做的事情。 通過此更改，崩潰消失了。

似乎當某些字符串登錄到分析中時， replaceAll()設法以某種方式破壞了字符串並導致它崩潰。 在這種情況下，關於replace()和replaceAll()之間差異的問題的答案似乎確實非常正確：使用錯誤的 function 可能會導致細微的錯誤。