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 <y...@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<y...@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>
>>
>
