android - ART prevents any Java calls from JNI during native signal handling -

my project use module of capturing crash , send in android system. when handling native crash, native code , java calls jni. works on dalvik. fails in android version above 5.0 using art. because art prevents java calls jni during native signal handling. says art signal handling uses alternate signal stack, during process of signal handing, can't call java methods? there other ways??
flow：
1. java call native method, native method crashes.
2. native crash handler catches signal handle crash.
3. during process of crash handling, calling jni method failed

12-31 20:36:02.516 7845-7957 a/art: art/runtime/check_jni.cc:65] jni detected error in application: jni issameobject called pending exception 'java.lang.stackoverflowerror' thrown in... in call issameobject stack=0x9fff8000-0x9fffa000 stacksize=1036kb 

reference:https://code.google.com/p/android/issues/detail?id=162663
nice if working art and/or bionic that.

your project relies on undefined behavior.

any signal handler can safely make only calls async-signal-safe functions. other function call invokes undefined behavior. relying on java/dalvik/art virtual machine limit async-signal-safe function calls in situation unrealistic @ best , quite plain incorrect.

your handler arbitrary signal can called @ time, leaving vm in possible state. there no way safely make java calls jni signal handler, , it's unreasonable expect try supporting such calls - how vm's designers allow signal interrupt synchronized method if signal handler allowed make calls synchronized on same object? if did that, they'd break language violating meaning of synchronized. if didn't that, they'd allow deadlocks such calls try lock object can never unlocked because signal interrupted processing.

in short, java calls via jni signal handler fundamentally unsupportable.

the fact used work gave expectation continue so.

you lucky in past.

it no longer works, , can't expect work in future.

and if hack working somehow, it's still fundamentally unsound. calls safe make within signal handler, per the posix standard, are:

the following table defines set of functions shall either reentrant or non-interruptible signals , shall async-signal-safe. therefore applications may invoke them, without restriction, signal-catching functions:

_exit() _exit() abort() accept() access() aio_error() aio_return() aio_suspend() alarm() bind() cfgetispeed() cfgetospeed() cfsetispeed() cfsetospeed() chdir() chmod() chown() clock_gettime() close() connect() creat() dup() dup2() execle() execve() fchmod() fchown() fcntl() fdatasync() fork() fpathconf() fstat() fsync() ftruncate() getegid() geteuid() getgid() getgroups() getpeername() getpgrp() getpid() getppid() getsockname() getsockopt() getuid() kill() link() listen() lseek() lstat() mkdir() mkfifo() open() pathconf() pause() pipe() poll() posix_trace_event() pselect() raise() read() readlink() recv() recvfrom() recvmsg() rename() rmdir() select() sem_post() send() sendmsg() sendto() setgid() setpgid() setsid() setsockopt() setuid() shutdown() sigaction() sigaddset() sigdelset() sigemptyset() sigfillset() sigismember() sleep() signal() sigpause() sigpending() sigprocmask() sigqueue() sigset() sigsuspend() sockatmark() socket() socketpair() stat() symlink() sysconf() tcdrain() tcflow() tcflush() tcgetattr() tcgetpgrp() tcsendbreak() tcsetattr() tcsetpgrp() time() timer_getoverrun() timer_gettime() timer_settime() times() umask() uname() unlink() utime() wait() waitpid() write() 

all functions not in above table considered unsafe respect signals. in presence of signals, functions defined volume of ieee std 1003.1-2001 shall behave defined when called or interrupted signal-catching function, single exception: when signal interrupts unsafe function , signal-catching function calls unsafe function, behavior undefined.

since there no way can ever guarantee making java call via jni within signal handler make calls async-signal-safe functions, there's no way can ever expect undefined behavior.