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>
