New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x/mobile: Process crashed as JNI exception isn't cleaned before next call. #21033

Open
xiaokangwang opened this Issue Jul 16, 2017 · 2 comments

Comments

Projects
None yet
4 participants
@xiaokangwang

xiaokangwang commented Jul 16, 2017

What version of Go are you using (go version)?

go1.8.3

(
gomobile version +0f31740 Wed Apr 19 17:20:05 2017 +0000 (android); androidSDK=[removed]/platforms/android-26
)

What operating system and processor architecture are you using (go env)?

linux/amd64

cross complied to

android/arm

What did you do?

Calling Java function from go part of android app(with interface), and an unchecked exception was thrown at Java side.

This is the abridged version of original crash log:

07-15 21:00:20.352 2854-2854/? A/DEBUG: Abort message: 'art/runtime/java_vm_ext.cc:410] JNI DETECTED ERROR IN APPLICATION: JNI CallStaticVoidMethod called with pending exception java.lang.IllegalStateException: Already closed'
07-15 21:00:20.352 2854-2854/? A/DEBUG:     x0   0000000000000000  x1   00000000000027c8  x2   0000000000000006  x3   0000000000000000
07-15 21:00:20.352 2854-2854/? A/DEBUG:     x4   0000000000000000  x5   0000000000000001  x6   0000000000000000  x7   0000000000000000
07-15 21:00:20.352 2854-2854/? A/DEBUG:     x8   0000000000000083  x9   000000000002fc80  x10  0000000001deffa0  x11  0000000001df00e0
07-15 21:00:20.352 2854-2854/? A/DEBUG:     x12  0000000000000000  x13  0000007fa1344000  x14  0000000000000000  x15  0000000000000000
07-15 21:00:20.352 2854-2854/? A/DEBUG:     x16  0000007fa1336568  x17  0000007fa12c92fc  x18  0000007fa1347f50  x19  0000007f81433500
07-15 21:00:20.352 2854-2854/? A/DEBUG:     x20  0000007f81433440  x21  000000000000000b  x22  0000000000000006  x23  0000007f823f4400
07-15 21:00:20.352 2854-2854/? A/DEBUG:     x24  0000007f979afc80  x25  0000000000000000  x26  0000007f9dcec000  x27  0000000000000000
07-15 21:00:20.352 2854-2854/? A/DEBUG:     x28  0000007f823f4400  x29  0000007f814328e0  x30  0000007fa12c6a98
07-15 21:00:20.352 2854-2854/? A/DEBUG:     sp   0000007f814328e0  pc   0000007fa12c9304  pstate 0000000020000000
07-15 21:00:20.357 2854-2854/? A/DEBUG: backtrace:
07-15 21:00:20.357 2854-2854/? A/DEBUG:     #00 pc 0000000000069304  /system/lib64/libc.so (tgkill+8)
07-15 21:00:20.357 2854-2854/? A/DEBUG:     #01 pc 0000000000066a94  /system/lib64/libc.so (pthread_kill+68)
07-15 21:00:20.357 2854-2854/? A/DEBUG:     #02 pc 00000000000239f8  /system/lib64/libc.so (raise+28)
07-15 21:00:20.357 2854-2854/? A/DEBUG:     #03 pc 000000000001e198  /system/lib64/libc.so (abort+60)
07-15 21:00:20.357 2854-2854/? A/DEBUG:     #04 pc 00000000004336c0  /system/lib64/libart.so (_ZN3art7Runtime5AbortEv+324)
07-15 21:00:20.357 2854-2854/? A/DEBUG:     #05 pc 0000000000136f78  /system/lib64/libart.so (_ZN3art10LogMessageD2Ev+3176)
07-15 21:00:20.357 2854-2854/? A/DEBUG:     #06 pc 000000000030f248  /system/lib64/libart.so (_ZN3art9JavaVMExt8JniAbortEPKcS2_+2080)
07-15 21:00:20.357 2854-2854/? A/DEBUG:     #07 pc 000000000030f6c8  /system/lib64/libart.so (_ZN3art9JavaVMExt9JniAbortVEPKcS2_St9__va_list+116)
07-15 21:00:20.357 2854-2854/? A/DEBUG:     #08 pc 0000000000142d34  /system/lib64/libart.so (_ZN3art11ScopedCheck6AbortFEPKcz+144)
07-15 21:00:20.357 2854-2854/? A/DEBUG:     #09 pc 0000000000149be4  /system/lib64/libart.so (_ZN3art11ScopedCheck5CheckERNS_18ScopedObjectAccessEbPKcPNS_12JniValueTypeE.constprop.116+6088)
07-15 21:00:20.358 2854-2854/? A/DEBUG:     #10 pc 000000000015c8f0  /system/lib64/libart.so (_ZN3art8CheckJNI11CallMethodVEPKcP7_JNIEnvP8_jobjectP7_jclassP10_jmethodIDSt9__va_listNS_9Primitive4TypeENS_10InvokeTypeE+948)
07-15 21:00:20.358 2854-2854/? A/DEBUG:     #11 pc 000000000015d72c  /system/lib64/libart.so (_ZN3art8CheckJNI20CallStaticVoidMethodEP7_JNIEnvP7_jclassP10_jmethodIDz+160)
07-15 21:00:20.358 2854-2854/? A/DEBUG:     #12 pc 00000000004f8038  /data/app/org.kkdev.v2raygo-1/lib/arm64/libgojni.so (go_seq_inc_ref+80)

I have successfully reproduced this crash. Try this binary apk(built with debug enabled):

app.zip

Reproduced log:

https://gist.github.com/xiaokangwang/8d7f5aefd98d7c52c644b4c815097eb5

Reproduce code:

Go part of reproduce

https://github.com/xiaokangwang/gomobilecrashreproducego

Java part of reproduce
https://github.com/xiaokangwang/gomobilecrashreproducejava

What did you expect to see?

Handle this situation gracefully, for example a API for dealing with unchecked exception, it can be:

  • a chan receiving unchecked exception if none is defined, the default handing comes in.
  • a runtime setting for defining what to do in this situation(quit or let it go)
  • a warn message at console/log if no policy is defined and an exception was thrown.

What did you see instead?

Just crash, and destabilize entire app.

This issue also have been spotted at ethereum/go-ethereum#14437, but seems to be ignored.

Original discovered as my app's service crash frequently and render it unusable.

@eliasnaur

This comment has been minimized.

Contributor

eliasnaur commented Oct 11, 2017

Why not return an error from the Java to the Go side? That way, the exception will be converted to a Go error automatically.

@xiaokangwang

This comment has been minimized.

xiaokangwang commented Nov 9, 2017

Some errors are triggered by Android or codes that outside developer's control. The only solution I found was use try and catch at all Java interface in hope that exceptions won't cause a crash.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment