Failed assert during VM_HeapWalkOperation
Zhengyu Gu
zgu at redhat.com
Fri Mar 27 01:11:05 UTC 2020
Hi Rodrigo,
There is an existing patch, you may want to try it.
http://cr.openjdk.java.net/~zgu/shenandoah/sh11u-jvmti/webrev.00/
Thanks,
-Zhengyu
On 3/26/20 6:17 PM, Rodrigo Bruno wrote:
> Dear Roman,
>
> I am using jdk 11.0.7 (checked out ~12 hours ago). I am pasting below part
> of the dump file. Sorry for the verbosity.
>
> Looking at https://bugs.openjdk.java.net/browse/JDK-8237632, it seems
> indeed to be the same issue. It this fix already in a public repo so that I
> can test?
>
> thanks!,
> rodrigo
>
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # Internal Error
> (/home/rbruno/mercurial/shenandoah/src/hotspot/share/gc/shenandoah/shenandoahForwarding.inline.hpp:47),
> pid=18485, tid=18490
> # Error: Shenandoah assert_correct failed; Forwardee must point to a heap
> address
>
> Referenced from:
> no interior location recorded (probably a plain heap scan, or detached
> oop)
>
> Object:
> 0x00000000c0004808 - klass 0x00000001000020f0 java.lang.Class
> not allocated after mark start
> marked
> not in collection set
> mark: marked(0x0000000000000003)
> region: | 0|R |BTE c0000000, c0080000, c0080000|TAMS
> c0080000|U 512K|T 512K|G 0B|S 0B|L 0B|CP 0|SN
> 1, 1, 0, 0
>
> Forwardee:
> 0x0000000000000000 - safe print, no details
>
>
> #
> # JRE version: OpenJDK Runtime Environment (11.0.7) (slowdebug build
> 11.0.7-internal+0-adhoc.rbruno.shenandoah)
> # Java VM: OpenJDK 64-Bit Server VM (slowdebug
> 11.0.7-internal+0-adhoc.rbruno.shenandoah, mixed mode, tiered, compressed
> oops, shenandoah gc, linux-amd64)
> # No core dump will be written. Core dumps have been disabled. To enable
> core dumping, try "ulimit -c unlimited" before starting Java again
> #
> # If you would like to submit a bug report, please visit:
> # http://bugreport.java.com/bugreport/crash.jsp
> #
>
> --------------- S U M M A R Y ------------
>
> Command Line: -XX:+UseShenandoahGC -XX:-UseBiasedLocking -Xlog:gc=trace
> -Xms1g -Xmx1g -Djava.library.path=. -agentpath:./libnaos.so ObjectCounter 5
> 4000000
>
> Host: ganymede, Intel(R) Xeon(R) CPU E3-1225 v6 @ 3.30GHz, 4 cores, 31G,
> Debian GNU/Linux 9 (stretch)
> Time: Thu Mar 26 21:58:00 2020 CET elapsed time: 78 seconds (0d 0h 1m 18s)
>
> --------------- T H R E A D ---------------
>
> Current thread (0x00007fd1202df890): VMThread "VM Thread" [stack:
> 0x00007fd102c22000,0x00007fd102d22000] [id=18490]
>
> Stack: [0x00007fd102c22000,0x00007fd102d22000], sp=0x00007fd102d1dd30,
> free space=1007k
> Native frames: (J=compiled Java code, A=aot compiled Java code,
> j=interpreted, Vv=VM code, C=native code)
> V [libjvm.so+0x13a357e] VMError::report_and_die(int, char const*, char
> const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, char const*,
> int, unsigned long)+0x7e2
> V [libjvm.so+0x13a2d39] VMError::report_and_die(Thread*, void*, char
> const*, int, char const*, char const*, __va_list_tag*)+0x57
> V [libjvm.so+0x8e874e] report_vm_error(char const*, int, char const*,
> char const*, ...)+0x152
> V [libjvm.so+0x8e85f9] report_vm_error(char const*, int, char const*)+0x39
> V [libjvm.so+0x1185eb6]
> ShenandoahAsserts::print_failure(ShenandoahAsserts::SafeLevel, oopDesc*,
> void*, oopDesc*, char const*, char const*, char const*, int)+0x39c
> V [libjvm.so+0x118611c] ShenandoahAsserts::assert_correct(void*,
> oopDesc*, char const*, int)+0x1c2
> V [libjvm.so+0x10047fb] ShenandoahForwarding::get_forwardee(oopDesc*)+0x29
> V [libjvm.so+0x100521e]
> ShenandoahBarrierSet::resolve_forwarded_not_null(oopDesc*)+0x18
> V [libjvm.so+0x11876d7]
> ShenandoahBarrierSet::load_reference_barrier_impl(oopDesc*)+0xad
> V [libjvm.so+0x11874af]
> ShenandoahBarrierSet::load_reference_barrier_not_null(oopDesc*)+0x55
> V [libjvm.so+0x7571e7] oopDesc*
> ShenandoahBarrierSet::AccessBarrier<1097844ul,
> ShenandoahBarrierSet>::oop_load_not_in_heap<oopDesc*>(oopDesc**)+0x3f
> V [libjvm.so+0x756ea4]
> AccessInternal::PostRuntimeDispatch<ShenandoahBarrierSet::AccessBarrier<1097844ul,
> ShenandoahBarrierSet>, (AccessInternal::BarrierType)2,
> 1097844ul>::oop_access_barrier(void*)+0x18
> V [libjvm.so+0x756aba] AccessInternal::RuntimeDispatch<1097812ul,
> oopDesc*, (AccessInternal::BarrierType)2>::load(void*)+0x1c
> V [libjvm.so+0x756a14] EnableIf<!HasDecorator<1097812ul, 4096ul>::value,
> oopDesc*>::type AccessInternal::PreRuntimeDispatch::load<1097812ul,
> oopDesc*>(void*)+0x37
> V [libjvm.so+0x75691d] oopDesc*
> AccessInternal::load_reduce_types<1097812ul, oopDesc*>(oopDesc**)+0x18
> V [libjvm.so+0x756816] oopDesc* AccessInternal::load<1048580ul, oopDesc*,
> oopDesc*>(oopDesc**)+0x25
> V [libjvm.so+0x756452] AccessInternal::OopLoadProxy<oopDesc*,
> 1048576ul>::operator oopDesc*()+0x1c
> V [libjvm.so+0x7bb4c7] OopHandle::resolve() const+0x45
> V [libjvm.so+0xe32dd0] Klass::java_mirror() const+0x1c
> V [libjvm.so+0xe2e264]
> VM_HeapWalkOperation::iterate_over_class(oopDesc*)+0x8c
> V [libjvm.so+0xe2f6b3] VM_HeapWalkOperation::visit(oopDesc*)+0xd1
> V [libjvm.so+0xe2988b] VM_HeapWalkOperation::doit()+0x1d7
> V [libjvm.so+0x13a6394] VM_Operation::evaluate()+0xde
> V [libjvm.so+0x13ea6b4] VMThread::evaluate_operation(VM_Operation*)+0x62
> V [libjvm.so+0x13ead61] VMThread::loop()+0x521
> V [libjvm.so+0x13ea22f] VMThread::run()+0x111
> V [libjvm.so+0x130e2d3] Thread::call_run()+0xc9
> V [libjvm.so+0x10515ba] thread_native_entry(Thread*)+0x1a2
>
> VM_Operation (0x00007fd12a5094d0): HeapWalkOperation, mode: safepoint,
> requested by thread 0x00007fd120074120
>
> Roman Kennke <rkennke at redhat.com> escreveu no dia quinta, 26/03/2020 à(s)
> 22:40:
>
>> Hello Rodrigo,
>>
>>> Dear Shenandoah dev list,
>>>
>>> my name is Rodrigo, I am an ETH postdoc researcher, and my group
>> currently
>>> has a project that involves using Shenandoah and tracing objects upon
>>> request by Java code (yes, many people will think this is a terrible
>>> idea... :-), I can explain if someone is interested...).
>>>
>>> We are using a slightly modified copy of the VM_HeapWalkOperation VM
>>> operation to trace objects starting for a particular initial object.
>>> However we started noticing failed asserts as soon as we introduced more
>>> load into the system (more allocations, leading to more GC effort).
>>>
>>> After some debugging, it turns out to be a load barrier check that fails
>>> during the VM_HeapWalkOperation because it i) sets the mark bits and ii)
>>> tries to resolve oops (triggering the barrier). For some reason, the gc
>>> state indicates that object headers should have the forwardee pointer in
>>> place and thus it fails. I saw that there is already an exception for
>> this
>>> particular VM op but it does not cover this path.
>>>
>>> This failed assert can be reproduced using an unmodified JDK. I just
>> tested
>>> it today by downloading [1], building, and creating a simple test which
>>> basically calls a JNI function that calls JVMTI FollowReferences. I can
>>> provide the sources to reproduce the failed assert. If I
>>> use -XX:ShenandoahGCMode=passive, no barriers are enabled and everything
>>> works fine. Dump file is attached.
>>>
>>> I think this might be a bug. Please let me know if you need any further
>>> information/help.
>>
>> This does indeed sound like a bug that we fixed recently:
>>
>>
>> https://mail.openjdk.java.net/pipermail/shenandoah-dev/2020-March/thread.html
>>
>> https://bugs.openjdk.java.net/browse/JDK-8237632
>>
>> and
>>
>> https://bugs.openjdk.java.net/browse/JDK-8237396
>>
>> Can you tell us which exact version you are using? The attachment has
>> been stripped by the mailing list.
>>
>> Thank you,
>> Roman
>>
>>
>
More information about the shenandoah-dev
mailing list