JNI Error Causing App Crash

[pelosi]

We are obtaining the frame object through the onFrame callback of RawVideoSink and immediately releasing it. However, after about 29 minutes, a JNI error occurs and the app crashes. Is there a way to avoid this or any alternative solution? If this is an issue within the SDK, please fix it as soon as possible.
When the chairman visited Korea, Parrot promised support for our Parrot SDK-related software development. I hope this issue can be resolved soon.

java_vm_ext.cc:675] JNI ERROR (app bug): global reference table overflow (max=51200)global reference table dump:
java_vm_ext.cc:675] Last 10 entries (of 51200):
java_vm_ext.cc:675] 51199: 0x6f1952b8 java.lang.Class<java.nio.ByteBuffer>
java_vm_ext.cc:675] 51198: 0x6f1952b8 java.lang.Class<java.nio.ByteBuffer>
java_vm_ext.cc:675] 51197: 0x6f1952b8 java.lang.Class<java.nio.ByteBuffer>
java_vm_ext.cc:675] 51196: 0x6f1952b8 java.lang.Class<java.nio.ByteBuffer>
java_vm_ext.cc:675] 51195: 0x6f1952b8 java.lang.Class<java.nio.ByteBuffer>
java_vm_ext.cc:675] 51194: 0x6f1952b8 java.lang.Class<java.nio.ByteBuffer>
java_vm_ext.cc:675] 51193: 0x6f1952b8 java.lang.Class<java.nio.ByteBuffer>
java_vm_ext.cc:675] 51192: 0x6f1952b8 java.lang.Class<java.nio.ByteBuffer>
java_vm_ext.cc:675] 51191: 0x6f1952b8 java.lang.Class<java.nio.ByteBuffer>
java_vm_ext.cc:675] 51190: 0x6f1952b8 java.lang.Class<java.nio.ByteBuffer>
…
runtime.cc:669] Runtime aborting…
runtime.cc:669] All threads:
runtime.cc:669] DALVIK THREADS (62):
runtime.cc:669] “Camera Live Decoder Thread” prio=5 tid=61 Runnable
runtime.cc:669] | group="" sCount=0 ucsCount=0 flags=0 obj=0x14045bc8 self=0x7b6b77cac0
runtime.cc:669] | sysTid=11063 nice=0 cgrp=default sched=0/0 handle=0x796b7fbcb0
runtime.cc:669] | state=R schedstat=( 74696969223 14995213011 110638 ) utm=6166 stm=1303 core=4 HZ=100
runtime.cc:669] | stack=0x796b6f8000-0x796b6fa000 stackSize=1039KB
runtime.cc:669] | held mutexes= “abort lock” “mutator lock”(shared held)
runtime.cc:669] native: #00 pc 0000000000567274 /apex/com.android.art/lib64/libart.so (art::DumpNativeStack(std::__1::basic_ostream<char, std::__1::char_traits >&, int, BacktraceMap*, char const*, art::ArtMethod*, void*, bool)+140)
runtime.cc:669] native: #01 pc 0000000000680184 /apex/com.android.art/lib64/libart.so (art::DumpStack(std::__1::basic_ostream<char, std::__1::char_traits >&, bool, BacktraceMap*, bool) const+356)
runtime.cc:669] native: #02 pc 000000000069e6ec /apex/com.android.art/lib64/libart.so (art::DumpCheckpoint::Run(art::Thread*)+916)
runtime.cc:669] native: #03 pc 0000000000698124 /apex/com.android.art/lib64/libart.so (art::ThreadList::RunCheckpoint(art::Closure*, art::Closure*)+524)
runtime.cc:669] native: #04 pc 00000000006970fc /apex/com.android.art/lib64/libart.so (art::ThreadList::Dump(std::__1::basic_ostream<char, std::__1::char_traits >&, bool)+972)
runtime.cc:669] native: #05 pc 000000000062fd80 /apex/com.android.art/lib64/libart.so (art::Runtime::Abort(char const*)+2216)
runtime.cc:669] native: #06 pc 0000000000015aa0 /system/lib64/libbase.so (android::base::SetAborter(std::__1::function<void (char const*)>&&)::$_3::__invoke(char const*)+80)
runtime.cc:669] native: #07 pc 000000000001508c /system/lib64/libbase.so (android::base::LogMessage::~LogMessage()+364)
runtime.cc:669] native: #08 pc 00000000004564f8 /apex/com.android.art/lib64/libart.so (art::JavaVMExt::AddGlobalRef(art::Thread*, art::ObjPtrart::mirror::Object)+296)
runtime.cc:669] native: #09 pc 00000000004cc23c /apex/com.android.art/lib64/libart.so (art::JNI::NewGlobalRef(_JNIEnv*, _jobject*)+612)
runtime.cc:669] native: #10 pc 00000000004470a8 /apex/com.android.art/lib64/libart.so (art::(anonymous namespace)::CheckJNI::NewRef(char const*, _JNIEnv*, _jobject*, art::IndirectRefKind)+720)
runtime.cc:669] native: #11 pc 0000000000195900 /data/app/~~IMO8-oLW2JngxiHwam9iyw==/com.jchyun.dronerts.fpvparrot-WBq2LXdomPHSGlS5o2EGqA==/base.apk!libsdkcore.so (offset 547000) (Java_com_parrot_drone_sdkcore_stream_SdkCoreRawSink_00024Frame_nativeClassInit+20)
runtime.cc:669] native: #12 pc 00000000021fc88c /memfd:jit-cache (deleted) (offset 2000000) (art_jni_trampoline+108)
runtime.cc:669] native: #13 pc 00000000020ec34c /memfd:jit-cache (deleted) (offset 2000000) (com.parrot.drone.sdkcore.stream.SdkCoreRawSink$Frame.access$nativeClassInit+76)
runtime.cc:669] native: #14 pc 00000000020b34c8 /memfd:jit-cache (deleted) (offset 2000000) (com.parrot.drone.sdkcore.stream.SdkCoreRawSink$Frame$Companion.nativeClassInit+88)
runtime.cc:669] native: #15 pc 000000000203d548 /memfd:jit-cache (deleted) (offset 2000000) (com.parrot.drone.sdkcore.stream.SdkCoreRawSink$Frame$Companion.access$nativeClassInit+88)
runtime.cc:669] native: #16 pc 0000000002170134 /memfd:jit-cache (deleted) (offset 2000000) (com.parrot.drone.sdkcore.stream.SdkCoreRawSink$Frame.constructor-impl+116)
runtime.cc:669] native: #17 pc 00000000020b72f0 /memfd:jit-cache (deleted) (offset 2000000) (com.parrot.drone.sdkcore.stream.SdkCoreRawSink.listenerHandler$lambda$1+192)
runtime.cc:669] native: #18 pc 00000000020610e4 /memfd:jit-cache (deleted) (offset 2000000) (com.parrot.drone.sdkcore.stream.SdkCoreRawSink.$r8$lambda$FakteTJ0PWO-3X_dWUFvwlK6clk+84)
runtime.cc:669] native: #19 pc 0000000000211608 /apex/com.android.art/lib64/libart.so (nterp_helper+152)

[teiszler]

Hi @pelosi,

Do you have a sample you can show on how to create the RawVideoSink and receive the frames via callback? It seems one must start with RawVideoSink.config but it is unclear how to even perform this configuration step. What does one pass as the looper if we just want to use the main thread looper? Can we just use ‘this’ as the callback if we have the MainActivity implement RawVideoSink.Callback?

Regarding your issue, the documentation does suggest if you spend too much time with the frame that is bound to the hardware decoder buffers, that stalling/crashing can occur. You may be able to copy() the frame data and immediately release it to avoid the behavior you are seeing.

Regards,
Tom

[pelosi]

After starting a new handler thread object, you can open a sink in the camera live using the config object, enabling you to retrieve video frames from the onframe callback.
when the video frames are no longer in use, you need to call releaseglobalref on the JNI sink object to remove the global reference.
I believe that the RawVideoSink development team should make improvements to address this issue.