ART prevents any Java calls from JNI during native signal handling [37035211]

Obsolete

Customer Issue

[AOSP] Question

Status Update

No update yet.

Description

sb...@opera.com

created issue #1

Apr 1, 2015 09:37AM

As described in

https://groups.google.com/forum/#!topic/android-ndk/fjOE3VvZkXc the new ART runtime disallows any calls to Java from JNI from within a native signal handler. This was not a problem on Dalvik where the same native code could access Java code without any problems.

We also use Breakpad to catch the native crash and the behavior has been observed on Nexus 7 and Nexus 5 (Android 5.0).

What is preventing ART from allowing the same behavior as Dalvik in this case? Is there something we can do to work around it?

Comments

en...@google.com <en...@google.com> Apr 1, 2015 02:56PM

Assigned to bd...@google.com.

bd...@google.com <bd...@google.com> Apr 1, 2015 03:10PM

Status: Won't Fix (Obsolete)

ag...@google.com <ag...@google.com> #2Apr 1, 2015 03:51PM

12-01 13:57:46.620: W/art(1617): JNI WARNING: java.lang.StackOverflowError thrown while calling printStackTrace

ART uses an alternate stack for signal handling, as crappy native code has happily filled our stack before, and we really like to be able to run the signal handler.

We currently use the bionic-provided altstack, which is pretty small. A workaround is to install a larger altstack when using breakpad.

en...@google.com <en...@google.com> #3Apr 1, 2015 03:56PM

(but note that very few functions are specified by POSIX to be guaranteed to work from a signal handler anyway.)

sb...@opera.com <sb...@opera.com> #4Apr 4, 2015 08:52AM

Thanks for the input. So is it the fact that ART uses this alternate stack that changes the behavior compared to Dalvik?

Breakpad actually increases the alt stack size to std::max(16384, SIGSTKSZ) already, is there some larger minimum for ART to allow calls to Java in this case?

bd...@google.com <bd...@google.com> #5Apr 4, 2015 11:47PM

If you have a problem with Breakpad, please talk to Breakpad authors? As far as I know, others are using it.

de...@gmail.com <de...@gmail.com> #6Apr 8, 2015 01:03PM

alt stack is only for breadkpad?
Is it same to sigalstack ?
I did not use breakpad ,can I fix this problem ?

de...@gmail.com <de...@gmail.com> #7Apr 8, 2015 01:09PM

I try to siglstack to 100k ,but it still not work ...

xu...@gmail.com <xu...@gmail.com> #8Apr 21, 2015 04:08AM

You can create a new thread in the 'breakpad_callback' method and then make JNI call in the thread.It will work.

sb...@opera.com <sb...@opera.com> #9Apr 21, 2015 11:26AM

This is not specific to Breakpad but rather I believe it is a consequence of using an alternate signal stack all together which Bionic itself will enable. The pthread initialization in Bionic fiddles around with the thread stack and puts the pthread_internal_t reference there (

https://github.com/android/platform_bionic/blob/master/libc/bionic/pthread_create.cpp#L167-169):

// Mapped space(or user allocated stack) is used for:
// pthread_internal_t
// thread stack (including guard page)

If I were to guess there is some assumption of finding this object adjacent to the stack base pointer when ART is requested to run a Java method from native code but in the alternate signal stack no such pthread setup/init would have been done causing the failure to call any Java methods from it due to not finding the pthread_internal_t.

Would be nice if someone working with ART and/or Bionic could look into that.