Android mystery cra * sh in libicuu c .so (utext_close) - PullRequest
Новая
       21

Android mystery cra * sh in libicuu c .so (utext_close)

0 голосов
/ 21 апреля 2020

Наша игра Android начала регистрировать странные сбои в разделе ANRs и сбоев в Google Play после последнего обновления. 

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(":", "");
}

Мы не смогли воспроизвести cra sh сами. Поэтому нам нужно немного подождать, чтобы сделать и выпустить новое обновление, где мы отключаем этот кусок кода и посмотрим, исчезнет ли cra sh.

Я просто нахожу странным, что стандартные замены строк могут вызвать что-то нравится. Кто-нибудь еще сталкивался с подобными сбоями?

1 Ответ

0 голосов
/ 27 апреля 2020

Проблема была на самом деле в неправильной функции замены строки.

В документации API говорится, что replaceAll() метод

Заменяет каждую подстроку этой строки, которая соответствует данное регулярное выражение с заданной заменой.

Я изменил код для использования replace() метода

Заменяет каждую подстроку этой строки, которая соответствует буквальной цели sequence указанной литеральной последовательностью замены.

Это на самом деле то, что код, предназначенный сделать в первую очередь. С этим изменением исчезли сбои.

Кажется, что когда определенные строки, вошедшие в аналитику, replaceAll() каким-то образом разбили строку и вызвали ее к sh. Этот ответ на вопрос о различиях между replace() и replaceAll() в данном случае выглядит действительно очень правдоподобным: Использование неправильной функции может привести к незначительным ошибкам.

...