SIGABRT on Android calling Java_com_squareup_zstd_JniZstdKt_createJniZstd

[ryannickel-autodesk]

I don't have steps to reproduce but from our bug reporting service we have seen this crash.

0  libc.so!libc.so +0x76360       abort
1  libart.so +0x8fdf2c            art::Runtime::Abort(char const*)
2  libbase.so!libbase.so +0x16548 android::base::SetAborter(std::__1::function<void (char const*)>&&)::$_0::__invoke(char const*)
3  libbase.so!libbase.so +0x15a48 android::base::LogMessage::~LogMessage()
4  libart.so +0x26bdc4            art::Thread::AssertNoPendingException() const
5  libart.so +0x206bac            art::ClassLinker::FindClass(art::Thread*, char const*, unsigned long, art::Handle<art::mirror::ClassLoader>)
6  libart.so +0x61b2f0            art::JNI<false>::FindClass(_JNIEnv*, char const*)
7  libzstd-kmp.so +0x28b24        Java_com_squareup_zstd_JniZstdKt_createJniZstd

The error seems to stem from these two calls in this method:

  auto zstdCompressorClass = env->FindClass("com/squareup/zstd/ZstdCompressor");
  auto zstdDecompressorClass = env->FindClass("com/squareup/zstd/ZstdDecompressor");

The first one fails, and then since the second is called while there is an unhandled error from the first it crashes. It is something do with the call using the wrong ClassLoader so it can't find the class but I don't have any insights beyond that.

One possible fix is to avoid the use of FindClass all together:

Kotlin

internal val jniZstdPointer: Long = run {
  loadNativeLibrary()
  createJniZstd(JniZstdCompressor::class.java, JniZstdDecompressor::class.java)
}

@JvmName("createJniZstd") internal external fun createJniZstd(
  zstdCompressorClass: Class<*>,
  zstdDecompressorClass: Class<*>
): Long

Cpp

extern "C" JNIEXPORT jlong JNICALL
Java_com_squareup_zstd_JniZstdKt_createJniZstd(JNIEnv* env, jclass /*type*/,
                                              jclass zstdCompressorClass, jclass zstdDecompressorClass) {
  auto jniZstd = new JniZstd(env, zstdCompressorClass, zstdDecompressorClass);
  return reinterpret_cast<jlong>(jniZstd);
}

I'll try to contribute a fix when I have some time to do so. Reporting the issue in case someone else runs into the same error.

[JakeWharton]

Are you obfuscating? We seem to lack keep rules.

Although your approach would be really nice, too.

[ryannickel-autodesk]

Good call out. We are minimizing / obfuscating on our release builds so adding some ProGuard / R8 rules may also solve the problem. This also explains why I never saw it during development on a dev build where we don't do that.

I'll try some rules and if it works post them here. I think there would still be value in the proposed fix as then every consumer of this package wouldn't need to remember to add the rules.

[JakeWharton]

The rules can be bundled so they're applied automatically. No explicit action required by consumers.

[JakeWharton]

I like passing in the class because it allows them to still be obfuscated, but we still need rules for whatever else is reflected upon on the class object as well.

[Tolriq]

Just faced this seems until it's merged the smallest rules to add locally are

-keep class com.squareup.zstd.ZstdCompressor {
    int inputBytesProcessed;
    int outputBytesProcessed;
}

-keep class com.squareup.zstd.ZstdDecompressor {
    int inputBytesProcessed;
    int outputBytesProcessed;
}