debug version failed with -XX:+PrintMallocFree

[Yumin Qi]

OK, will not file bug.

Thanks
Yumin

On 4/9/2013 6:03 PM, David Holmes wrote:
> 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