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

[Staffan Larsen]

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

> I thought your code too. However...
> 
> - These code is different from other code (rule?).

Well, you are introducing a new macro that is also different from other code, so I'm not sure how valid that argument is.

> - Similar crash cases exist. e.g. 6425580 and 7142442.
>   These crashes are different from 6989981. However, I guess that crashed
>   thread had pending exception and we need to fix with similar patch.
> 
> So I think that new macro is useful later.

Yes, similar problems may come up in other cases as well.

Generally, I don't think it's a good idea to have logging calls hidden away in general macros. What we really should do here is print some context around the stack trace as well. Something like:

    Initializing the attach listener failed with the following exception in AttachListener::init when initializing the thread_oop:

This would be possible with the code I suggested, but very hard in a general macro.

Thanks,
/Staffan


> 
> 
> Thanks,
> 
> Yasumasa
> 
> On 2013/09/20 23:05, Staffan Larsen wrote:
>> 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>
>>>> 
>>> 
>> 
>