message thread crash (accessed stale global reference)

压力测试中出现一处crash

有如下信息：`JNI ERROR (app bug): accessed stale global reference 0x6fa (index 446 in a table of size 446)`

对应堆栈：
```
01-11 22:27:43.661 F/DEBUG ( 2441): Abort message: 'art/runtime/indirect_reference_table.cc:65] JNI ERROR (app bug): see above.'
01-11 22:27:43.662 F/DEBUG ( 2441): r0 00000000 r1 00005736 r2 00000006 r3 da2ef978
01-11 22:27:43.662 F/DEBUG ( 2441): r4 da2ef980 r5 da2ef930 r6 00000002 r7 0000010c
01-11 22:27:43.662 F/DEBUG ( 2441): r8 f4eff800 r9 f4efde44 sl e1d182db fp f4ee3838
01-11 22:27:43.662 F/DEBUG ( 2441): ip 00000006 sp da2ef348 lr f6fa7115 pc f6fa968c cpsr 400f0010
01-11 22:27:43.677 F/DEBUG ( 2441):
01-11 22:27:43.677 F/DEBUG ( 2441): backtrace:
01-11 22:27:43.677 F/DEBUG ( 2441): #00 pc 0004268c /system/lib/libc.so (tgkill+12)
01-11 22:27:43.677 F/DEBUG ( 2441): #01 pc 00040111 /system/lib/libc.so (pthread_kill+32)
01-11 22:27:43.678 F/DEBUG ( 2441): #02 pc 0001c8cf /system/lib/libc.so (raise+10)
01-11 22:27:43.678 F/DEBUG ( 2441): #03 pc 00019a81 /system/lib/libc.so (__libc_android_abort+34)
01-11 22:27:43.678 F/DEBUG ( 2441): #04 pc 00017620 /system/lib/libc.so (abort+4)
01-11 22:27:43.678 F/DEBUG ( 2441): #05 pc 0031f589 /system/lib/libart.so (_ZN3art7Runtime5AbortEv+212)
01-11 22:27:43.678 F/DEBUG ( 2441): #06 pc 000f3969 /system/lib/libart.so (_ZN3art10LogMessageD2Ev+2092)
01-11 22:27:43.678 F/DEBUG ( 2441): #07 pc 000f0197 /system/lib/libart.so (_ZN3art7BarrierD2Ev+182)
01-11 22:27:43.678 F/DEBUG ( 2441): #08 pc 00345ac9 /system/lib/libart.so (_ZN3art10ThreadList4DumpERNSt3__113basic_ostreamIcNS1_11char_traitsIcEEEE+144)
01-11 22:27:43.678 F/DEBUG ( 2441): #09 pc 0031f645 /system/lib/libart.so (_ZN3art7Runtime5AbortEv+400)
01-11 22:27:43.678 F/DEBUG ( 2441): #10 pc 000f3969 /system/lib/libart.so (_ZN3art10LogMessageD2Ev+2092)
01-11 22:27:43.678 F/DEBUG ( 2441): #11 pc 001d39db /system/lib/libart.so (_ZN3art22IndirectReferenceTable17AbortIfNoCheckJNIEv+62)
01-11 22:27:43.678 F/DEBUG ( 2441): #12 pc 0024cb3f /system/lib/libart.so (_ZN3art9JavaVMExt12DecodeGlobalEPNS_6ThreadEPv+322)
01-11 22:27:43.679 F/DEBUG ( 2441): #13 pc 0033bc19 /system/lib/libart.so (_ZNK3art6Thread13DecodeJObjectEP8_jobject+140)
01-11 22:27:43.679 F/DEBUG ( 2441): #14 pc 00317fd9 /system/lib/libart.so (_ZN3art17InvokeWithVarArgsERKNS_33ScopedObjectAccessAlreadyRunnableEP8_jobjectP10_jmethodIDSt9__va_list+384)
01-11 22:27:43.679 F/DEBUG ( 2441): #15 pc 0026efdd /system/lib/libart.so (_ZN3art3JNI20CallStaticVoidMethodEP7_JNIEnvP7_jclassP10_jmethodIDz+324)
01-11 22:27:43.679 F/DEBUG ( 2441): #16 pc 0002d911 /data/app/xxx/lib/arm/libijksdl.so (J4AC_tv_danmaku_ijk_media_player_IjkMediaPlayer__postEventFromNative+36)
01-11 22:27:43.679 F/DEBUG ( 2441): #17 pc 00037c79 /data/app/xxx/lib/arm/libijkplayer.so
01-11 22:27:43.679 F/DEBUG ( 2441): #18 pc 00010423 /data/app/xxx/lib/arm/libijksdl.so
01-11 22:27:43.679 F/DEBUG ( 2441): #19 pc 0003fa13 /system/lib/libc.so (_ZL15__pthread_startPv+30)
01-11 22:27:43.679 F/DEBUG ( 2441): #20 pc 0001a105 /system/lib/libc.so (__start_thread+6)
```

我的理解是：release的时候没有等待msg_thread退出，直接释放了weak_thiz，极端条件下，可能引发msg_thread访问到一个已被释放的reference.

具体分析如下，能帮忙确认下我的分析是否正确吗？

release过程：
```
static void
IjkMediaPlayer_release(JNIEnv *env, jobject thiz)
{//……
ijkmp_shutdown(mp); //note: 这里没有join mp->_msg_thread

jobject weak_thiz = (jobject) ijkmp_set_weak_thiz(mp, NULL );
(*env)->DeleteGlobalRef(env, weak_thiz); //note：这里释放了weak_thiz，但有可能_msg_thread仍然在运行
//……
ijkmp_dec_ref_p(&mp);//note: 当mp计数0,在ijkmp_destroy中等待msg_thread退出
}

static int message_loop(void *arg)
{
LABEL_RETURN:
ijkmp_dec_ref_p(&mp); //note: msg_thread也有可能在自己的线程结束时才退出
}
```

因此，如果在DeleteGlobalRef后，ijkmp_destroy join msg_thread之前，恰好调用了post_event，那么就会出现上面的问题。

想请教下，上面的分析正确吗？是否有好的解决方法？

Start with IjkMediaPlayer_release, ijkmp_shutdown, ijkmp_destroy, and message_loop, tracing the lifetime of weak_thiz and the message thread during stress testing. Confirm whether postEventFromNative can run after DeleteGlobalRef; done means the stale global-reference crash is reproduced or ruled out and the issue has a justified resolution.

Written by the indexing model from the issue text.