JDK-6989981: jstack causes "fatal error: ExceptionMark destructor expects no pending exceptions"

[Yasumasa Suenaga]

Hi,

I encountered this bug:
   JDK-6989981: jstack causes "fatal error: ExceptionMark destructor expects no pending exceptions"

I read hs_err and attachListener.cpp, Java heap usage is very high and
it could be OutOfMemoryError in AttachListener::init() .

If JavaCalls::call_special() in AttachListener::init() fail which is
caused by OOME, d'tor of EXCEPTION_MARK (~ExceptionMark) will generate
internal error.

So I make a patch for avoiding crash and attached in this email (6989981.patch) .
I'd like to re-open this bug and contribute my patch.
Could you help me?


--- DETAILS ---
CHECK macro is used in JavaCalls::call_special() .

******************
void AttachListener::init() {
   EXCEPTION_MARK;

        :

   // Initialize thread_oop to put it into the system threadGroup
   Handle thread_group (THREAD, Universe::system_thread_group());
   JavaValue result(T_VOID);
   JavaCalls::call_special(&result, thread_oop,
                        klass,
                        vmSymbols::object_initializer_name(),
                        vmSymbols::threadgroup_string_void_signature(),
                        thread_group,
                        string,
                        CHECK);

   KlassHandle group(THREAD, SystemDictionary::ThreadGroup_klass());
   JavaCalls::call_special(&result,
                         thread_group,
                         group,
                         vmSymbols::add_method_name(),
                         vmSymbols::thread_void_signature(),
                         thread_oop,             // ARG 1
                         CHECK);
******************

CHECK macro does not clear pending exception of current thread.
So call_special() fails with runtime exception, d'tor of ExceptionMark
generates fatal error.

******************
ExceptionMark::~ExceptionMark() {
   if (_thread->has_pending_exception()) {
     Handle exception(_thread, _thread->pending_exception());
     _thread->clear_pending_exception(); // Needed to avoid infinite recursion
     if (is_init_completed()) {
       exception->print();
       fatal("ExceptionMark destructor expects no pending exceptions");
     } else {
       vm_exit_during_initialization(exception);
     }
   }
}
******************


--- HOW TO REPRODUCE ---
I also crate testcase of this issue (testcase.tar.gz) . This testcase contains
two modules.

  - jvmti: JVMTI agent for this issue. This agent traps SIGQUIT and
           calls original (in HotSpot) SIGQUIT handler.
           This signal handler is invoked, MethodEntry event callback is
           enabled. MethodEntry generates OutOfMemoryError.

  - java : Simple long sleep program.

I can run this testcase in Fedora18 x86_64. See below.

-------
$ javac java/LongSleep.java
$ make -C jvmti
make: Entering directory `/data/share/patch/ExceptionMark/testcase/jvmti'
gcc -I/usr/lib/jvm/java-openjdk/include -I/usr/lib/jvm/java-openjdk/include/linux -fPIC -c oome.c
gcc -shared -o liboome.so oome.o
make: Leaving directory `/data/share/patch/ExceptionMark/testcase/jvmti'
$ export JAVA_HOME=</path/to/jre>
$ ./test.sh
-------



Best regards,

Yasumasa

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 6989981.patch
Url: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130920/2f895862/6989981.patch 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: testcase.tar.gz
Type: application/x-gzip-compressed
Size: 1446 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130920/2f895862/testcase.tar.gz