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

Thomas Schatzl thomas.schatzl at oracle.com
Fri Apr 26 06:41:26 UTC 2019


Hi again,

  by coincidence I just found a similar recent issue with smartctl in
the bug tracker: https://bugs.openjdk.java.net/browse/JDK-8220216

Same issue here: you run smartctl, and the VM crashes with random
apparent memory overwrite, in this case modifying some internal object
metadata too.

Thanks,
  Thomas

On Fri, 2019-04-26 at 02:43 +0000, shang xinli wrote:
> Thanks Andrew and Thomas!
> 
> Sent from my iPhone
> 
> > On Apr 25, 2019, at 12:45 AM, Thomas Schatzl <
> > thomas.schatzl at oracle.com> wrote:
> > 
> > Hi,
> > 
> > > On Wed, 2019-04-24 at 20:01 +0000, shang xinli wrote:
> > > Thanks Andrew! 
> > > 
> > > Can you explain a little bit more why the displayed hdr count
> > > implicit memory corruption? I don't quite understand why the lock
> > > contention is connected with memory corruption. 
> > 
> >  that guarentee basically checks that values calculated twice in
> > different ways at the end of gc correspond with each other.
> > 
> > Just by looking at the verification code a bit:
> > - once by traversing the objects directly as CMS links the promoted
> > (copied) objects together during GC (in the object header) and
> > counting
> > the objects that had a lock on them (also stored in that link).
> > 
> > - once by looking at a data structure (basically a list of arrays)
> > that
> > stores all these references to the locks, and counting the number
> > of
> > entries. (CMS had to store the original values somewhere because it
> > used the header for linking together the promoted objects)
> > 
> > -----
> > 
> > This guarantee apparently never failed before, and a search in the
> > bugtracker did not show anything either, but CMS has been
> > considered
> > "complete" before my time working on Hotspot... :)
> > 
> > Also a (different) crash happens with G1, which has a completely
> > different implementation than CMS - G1 does not link together
> > promoted
> > objects during gc.
> > 
> > The code in question changed last in 2010 - and that has been a
> > move
> > into a separate file.
> > 
> > The crashes only occur when using an external tool.
> > 
> > Given all this and probably more reasons the most likely (initial)
> > area I would look at is the external tool.
> > 
> > Because of this Andrew also almost immediately said "You do not
> > have a
> > bug in the GC". I agree.
> > 
> > There is no good recipe in tracking down such bugs unfortunately.
> > 
> > Thanks,
> >  Thomas
> > 
> > 





More information about the hotspot-gc-dev mailing list