Failed assert during VM_HeapWalkOperation
Rodrigo Bruno
rodrigo.bruno at inf.ethz.ch
Fri Mar 27 08:36:34 UTC 2020
Dear Zhengyu,
thanks, the patch seems to solve the issue! Is there a way to track this so
that I know once this patch makes into
http://hg.openjdk.java.net/shenandoah/jdk11?
best,
rodrigo
Zhengyu Gu <zgu at redhat.com> escreveu no dia sexta, 27/03/2020 à(s) 02:11:
> 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
> >>
> >>
> >
>
>
--
rodrigo-bruno.github.io
More information about the shenandoah-dev
mailing list