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

[Staffan Larsen]

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>