I thought your code too. However... - These code is different from other code (rule?). - 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. 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<[email protected]> 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<[email protected]> 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>
