li-feng-sc
commented
1 year ago Hi @tongyuze, do you have more details about the crash?
We don't see any problem with djinni::jniFindClass in Snapchat.
Open tongyuze opened 1 year ago
li-feng-sc
commented
1 year ago Hi @tongyuze, do you have more details about the crash?
We don't see any problem with djinni::jniFindClass in Snapchat.
tongyuze
commented
11 months ago @LiFengSC We got another similar crash recently. The stacktrace is like this:
djinni::jniGetThreadEnv() [0xd2f1708] in jni.h:1062 djinni::jniFindClass(char const*) [0xd2f1788] in djinni_support.cpp:300 djinni_generated::NativeOneAuthTransaction::NativeOneAuthTransaction() [0xcf77bb8] in NativeOneAuthTransaction.hpp:27 djinni::JniClass::get() [0xcf77e10] in djinni_support.hpp:231
And the cause of the crash is: signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0 Cause: null pointer dereference
Any idea about this?
li-feng-sc
commented
11 months ago This looks djinni::jniInit() was not called for some reason.
djinni::jniInit() is usually called by your JNI_OnLoad function. There is an implementation of JNI_OnLoad in djinni_main.cpp if you link that file. You can try log that and see if this is called before jniFindClass()
tongyuze
commented
10 months ago @LiFengSC But for "g_cachedJVM", it is checked by "assert". I'm assuming this will not cause "null pointer dereference" error. Is that correct?
li-feng-sc
commented
10 months ago assert is a macro, so it is compiled out in release builds. in debug builds the assert line should trigger.
tongyuze
commented
10 months ago @LiFengSC So in production, if g_chachedJVM is not initialized, a "null pointer dereference" error will come out, is that correct?
Also want to check, there will be no exception thrown because of this error, so we can't use try-catch block in java file to catch and deal with this error, is that correct? The only way to solve this is to make sure djinni::jniInit() is called before.
tongyuze
commented
10 months ago And also we got another issue which should be non-related to my previous post: For this one, we got "ClassNotFoundException", but the final error pops out is: "local reference table overflow (max=512)". Do you have any idea about this?
Thread art/runtime/indirect_reference_table.cc:129] JNI ERROR (app bug): local reference table overflow (max=512)
backtrace:
Hi there,
We got some report that djinni::jniFindClass will crash sometimes while it is called by native thread. However, the thing is that we couldn't repro this issue and find any clue on our side.
Do you have any idea about how this method could fail? Thanks!