[RFR] 8196969: JTreg Failure: serviceability/sa/ClhsdbJstack.java causes NPE
Severin Gehwolf
sgehwolf at redhat.com
Wed Oct 2 08:39:05 UTC 2019
Hi Chris,
On Tue, 2019-10-01 at 12:51 -0700, Chris Plummer wrote:
> Hi Severin,
>
> Sorry, this is not an area that I have any expertise in. However, I did
> confirm that it fixes the NPE I was seeing with JShellHeapDumpTest.java,
> which brings up a question. You said this happens with -Xcomp, but I was
> never using -Xcomp. Might it also be triggered without -Xcomp?
Yes, as soon as C1/C2 kick in you might be seeing the issue. In fact, I
had one reproducer which triggered the issue quite reliably which
didn't use -Xcomp explicitly. Nevertheless, certain methods got JIT
compiled soon and the issue surfaced. You should be able to verify by
adding -XX:+PrintCompilation to the host program and/or comparing it to
-Xint runs.
TLDR; -Xcomp helps reproducing the issue on smaller test cases, but
isn't essential in the general case.
Does that make sense?
Thanks,
Severin
> thanks,
>
> Chris
>
> On 10/1/19 1:58 AM, Severin Gehwolf wrote:
> > Anyone? Chris maybe?
> >
> > On Fri, 2019-09-27 at 14:12 +0200, Severin Gehwolf wrote:
> > > Hi,
> > >
> > > Could I please get reviews for this SA fix? The issue only happens
> > > intermittently and with -Xcomp. The new regression test reproduces the
> > > issue somewhat reliably. I got 10/10 fails for unpatched, but I've seen
> > > it pass as well.
> > >
> > > When the issue happens, PCDesc's getScopeDecodeOffset() returs 0
> > > (DebugInformationRecorder.SERIALIZED_NULL). The current SA code doesn't
> > > handle this case and goes on and tries to read ScopeDesc from the
> > > DebugInfoReadStream at the bogus offset. From then on, bad things
> > > happen. A NPE in StackTrace could be one symptom.
> > >
> > > The same code in hotspot deals with serialized null differently. It
> > > doesn't read from the debug info stream, and manually sets up a
> > > reasonable frame. Note decode_body is called from ScopeDesc's
> > > constructor where decode_offset might have been set to 0:
> > >
> > > void ScopeDesc::decode_body() {
> > > if (decode_offset() == DebugInformationRecorder::serialized_null) {
> > > // This is a sentinel record, which is only relevant to
> > > // approximate queries. Decode a reasonable frame.
> > > _sender_decode_offset = DebugInformationRecorder::serialized_null;
> > > _method = _code->method();
> > > _bci = InvocationEntryBci;
> > > _locals_decode_offset = DebugInformationRecorder::serialized_null;
> > > _expressions_decode_offset = DebugInformationRecorder::serialized_null;
> > > _monitors_decode_offset = DebugInformationRecorder::serialized_null;
> > > } else {
> > > // decode header
> > > DebugInfoReadStream* stream = stream_at(decode_offset());
> > >
> > > _sender_decode_offset = stream->read_int();
> > > _method = stream->read_method();
> > > _bci = stream->read_bci();
> > >
> > > // decode offsets for body and sender
> > > _locals_decode_offset = stream->read_int();
> > > _expressions_decode_offset = stream->read_int();
> > > _monitors_decode_offset = stream->read_int();
> > > }
> > > }
> > >
> > > The proposed patch handles serialized null scopes similar to the
> > > hotspot side of things, by returning a null scope. CompiledVFrame
> > > already deals with null scopes when in debugging mode.
> > >
> > > Bug: https://bugs.openjdk.java.net/browse/JDK-8196969
> > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196969/03/webrev/
> > >
> > > Testing: tier 1 tests on Linux x86_64 (release/fastdebug). jdk-submit
> > > and ran various reproducer tests including 1000 interations of the
> > > added regression test. All pass.
> > >
> > > Thoughts?
> > >
> > > Thanks,
> > > Severin
More information about the serviceability-dev
mailing list