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