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

[Yasumasa Suenaga]

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>
>