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

[Staffan Larsen]

I see. CHECK_AND_CLEAR_AND_PRINT? Just kidding... :-)

Maybe in this case we should not have this as a macro, but actually add the code after the two calls to call_special? Something like the code below. I personally think this is more readable than obscure macros that I have to go look up to understand what they do.

Thanks,
/Staffan

  JavaCalls::call_special(&result, thread_oop,
                       klass,
                       vmSymbols::object_initializer_name(),
                       vmSymbols::threadgroup_string_void_signature(),
                       thread_group,
                       string,
                       THREAD);

  if (HAS_PENDING_EXCEPTION) {
    java_lang_Throwable::print(PENDING_EXCEPTION, tty);
    CLEAR_PENDING_EXCEPTION;
    return;
  }

  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
                        THREAD);

  if (HAS_PENDING_EXCEPTION) {
    java_lang_Throwable::print(PENDING_EXCEPTION, tty);
    CLEAR_PENDING_EXCEPTION;
    return;
  }




On 20 sep 2013, at 15:53, Yasumasa Suenaga <yasu at ysfactory.dip.jp> wrote:

> Hi Staffan,
> 
> Thank you for your sponsoring!
> 
> "CHECK_AND_CLEAR" is already defined in exceptions.hpp:
> ******************
> #define CHECK_AND_CLEAR                         THREAD); if (HAS_PENDING_EXCEPTION) { CLEAR_PENDING_EXCEPTION; return;        } (void)(0
> ******************
> 
> I think that user wants why serviceability tools are failed.
> So I defined "CHECK_AND_CLEAR" + java_lang_Throwable::print() as "CATCH_AND_RETURN" .
> 
> 
> I agree rename this macro.
> Do you have any idea? I don't have a good name :-)
> 
> 
> Thanks,
> 
> Yasumasa
> 
> On 2013/09/20 20:10, Staffan Larsen wrote:
>> Yasuma,
>> 
>> Thanks for finding and fixing this! I have re-opened the bug. Your patch looks good to me, but perhaps CATCH_AND_RETURN should be renamed CHECK_AND_CLEAR?
>> 
>> I can sponsor the fix.
>> 
>> Thanks,
>> /Staffan
>> 
>> On 20 sep 2013, at 12:41, Yasumasa Suenaga<yasu at ysfactory.dip.jp>  wrote:
>> 
>>> 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
>>> 
>>> <6989981.patch><testcase.tar.gz>
>> 
>