回复: 回复: 回复: JVM crashes constantly when High GC happens

[shang xinli]

Thanks, Andrew! I agree it could be because of memory corruption.  The issue only reproduced when a tool smartctl is kicked off. It has system call as below. Do you think it is possible that the device driver corrupts JVM's memory? How do I start investigating? Any use tool?


ioctl(3, SG_IO, {'S', SG_DXFER_FROM_DEV, cmd[16]=[85, 09, 0e, 00, 00, 00, 40, 00, 03, 00, 00, 00, 00, 00, 2f, 00], mx_sb_len=32, iovec_count=0, dxfer_len=32768, timeout=20000, flags=0, data[32768]=["\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...], status=00, masked_status=00, sb[0]=[], host_status=0, driver_status=0, resid=0, duration=5024, info=0}) = 0



发送自 Outlook<http://aka.ms/weboutlook>

________________________________
发件人: Andrew Haley <aph at redhat.com>
发送时间: 2019年4月23日 3:15
收件人: shang xinli; Kim Barrett; shade at redhat.com
抄送: hotspot-gc-dev at openjdk.java.net
主题: Re: 回复: 回复: JVM crashes constantly when High GC happens

On 4/19/19 11:08 PM, shang xinli wrote:
> I just reproduced it with the fastdebug build. Now it reports error at PromotionInfo:verify(). More specifically, it found numDisplaceHdrs NOT equal numObjWithDisplaceHdrs. It fails at below.
>
>
> guarantee(numDisplacedHdrs == numObjsWithDisplacedHdrs, "Displaced hdr count”);
>
> Here is the debug info. It would be great if somebody can help to
> guide how to instrument the code to find out the root cause.

There's no recipe that you can use here.

A displaced header occurs when an object is locked, so the object's
first word (with tag bits, etc.) is copied elswhere and replaced in
the object by a pointer to a structure. Displaced headers fairly
uncommon: it only happens when there is contention for a lock and a
thread is blocked. When a GC does its marking phase, it has to keep
track of displaced headers.

You do not have a bug in the GC. The problem is memory corruption. Are
you using any native libraries? That is where I would start.

--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20190423/0c7341f5/attachment.htm>