debug version failed with -XX:+PrintMallocFree

[David Holmes]

Hi Yumin,

This is a known issue with debug builds and some of the print/trace 
options. The more common one is you get recursive use of the low-level 
locking code that is not intended for recursive use. It is pretty much a 
"will not fix".

The stack below seems somewhat different, it looks like we're in the 
process of destroying the current thread when the debug println is 
executed, which tries to acquire a lock, which requires the current 
thread to be in a valid state, but it isn't. Not certain of the exact 
details for this case, so this case might be fixable.

A lot of our debug/tracing code is naive. It can get invoked from 
arbitrary places and arbitrary times and attempt to perform actions that 
are simply not possible from the current context.

David

On 10/04/2013 9:53 AM, Yumin Qi wrote:
> Hi,
>
>    Current build failed with
>    java -XX:+PrintMallocFree -version
>
> # To suppress the following error report, specify this argument
> # after -XX: or in .hotspotrc:  SuppressErrorAt=/mutex.cpp:454
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  Internal Error
> (/HUDSON/workspace/2-build-linux-i586/jdk8/3881/hotspot/src/share/vm/runtime/mutex.cpp:454),
> pid=19793, tid=3820346224
> #  assert(_OnDeck != Self->_MutexEvent) failed: invariant
> #
> # JRE version: Java(TM) SE Runtime Environment (8.0-b84) (build
> 1.8.0-ea-fastdebug-b84)
> # Java VM: Java HotSpot(TM) Client VM (25.0-b25-fastdebug mixed mode
> linux-x86 )
> # Failed to write core dump. Core dumps have been disabled. To enable
> core dumping, try "ulimit -c unlimited" before starting Java again
> #
> # An error report file with more information is saved as:
>
>
>      stack trace:
>
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code,
> C=native code)
> V  [libjvm.so+0x7f7bf4]  VMError::report_and_die()+0x1a4
> V  [libjvm.so+0x312058]  report_vm_error(char const*, int, char const*,
> char const*)+0x68
> V  [libjvm.so+0x7f7a2a]  VMError::report(outputStream*)+0x178a
> V  [libjvm.so+0x7f7bf4]  VMError::report_and_die()+0x1a4
> V  [libjvm.so+0x312058]  report_vm_error(char const*, int, char const*,
> char const*)+0x68
> V  [libjvm.so+0x63afd7]  Monitor::ILock(Thread*)+0x347
> V  [libjvm.so+0x63b6ba] Monitor::lock_without_safepoint_check()+0x3a
> V  [libjvm.so+0x68863a]  defaultStream::hold(int)+0xca
> V  [libjvm.so+0x688709]  defaultStream::write(char const*, unsigned
> int)+0x29
> V  [libjvm.so+0x68558a]  outputStream::print_cr(char const*, ...)+0x3a
> V  [libjvm.so+0xcb585]  Arena::operator delete(void*)+0x25
> V  [libjvm.so+0x7a059a]  Thread::~Thread()+0x1ca
> V  [libjvm.so+0x7a0a95]  JavaThread::~JavaThread()+0x2f5
> V  [libjvm.so+0x7a78ed]  JavaThread::thread_main_inner()+0x8d
> V  [libjvm.so+0x7a7d16]  JavaThread::run()+0x256
> V  [libjvm.so+0x67e599]  java_start(Thread*)+0x119
> C  [libpthread.so.0+0x6a49]  abort@@GLIBC_2.0+0x6a49
>
> Think it is a potential bug. Should I file a bug?
>
> Thanks
> Yumin