committed > max in MemoryMXBean#getHeapMemoryUsage()
Daniel Mitterdorfer
daniel.mitterdorfer at gmail.com
Thu Jul 19 17:10:09 UTC 2018
Hi Erik,
I am quite happy that I could reproduce it after running the tests
repeatedly for approximately a week after the first failure.
Glad I could help and thank you all for you help as well!
Daniel
Am Do., 19. Juli 2018 um 16:57 Uhr schrieb Erik Helin <erik.helin at oracle.com>:
>
> On 07/13/2018 04:10 PM, Daniel Mitterdorfer wrote:
> > Hi,
> >
> > I have good news. I was able to reproduce this issue but this time I
> > have logs. A test failed with the following stack trace around
> > 15:06:55 with:
> >
> > java.lang.IllegalArgumentException: committed = 537919488 should be <
> > max = 536870912
> > > at java.lang.management.MemoryUsage.<init>(MemoryUsage.java:166)
> > > at sun.management.MemoryImpl.getMemoryUsage0(Native Method)
> > > at sun.management.MemoryImpl.getHeapMemoryUsage(MemoryImpl.java:71)
> > > at org.elasticsearch.indices.breaker.HierarchyCircuitBreakerService.currentMemoryUsage(HierarchyCircuitBreakerService.java:242)
> >
> > This time it happened on Linux (kernel 4.13.0-45-generic) with JDK 10
> > (build 10+46). The JVM arguments were:
> >
> > -Xms512M -Xmx512M
> > -Xlog:gc*=trace,heap*=trace,tlab*=off:stdout:time,pid,tid,level,tags
> >
> > The logs are somewhat massive (~250MB uncompressed) and available at
> > https://www.dropbox.com/s/wir9sv1dk5cf54y/JDK-8207200_test_log.txt.zip?dl=0
>
> Thanks for the logs Daniel, they helped a lot! Me and Thomas looked
> through the logs and the code and as we suspected, this is code is a bit
> buggy :/ Please see the bug for more details:
>
> https://bugs.openjdk.java.net/browse/JDK-8207200
>
> Again, thanks for taking your time and reporting this issue and for
> getting us the logs, much appreciated!
> Erik
>
> > I hope that helps identifying the cause. Please let me know if you
> > need anything else.
> >
> > Daniel
> > Am Fr., 13. Juli 2018 um 10:33 Uhr schrieb Thomas Schatzl
> > <thomas.schatzl at oracle.com>:
> >>
> >> On Fri, 2018-07-13 at 10:30 +0200, Daniel Mitterdorfer wrote:
> >>> Hi Erik,
> >>>>
> >>>> Do you any kind of GC logging from the test run where you
> >>>> encountered the bug?
> >>>
> >>> Unfortunately, we don't have GC logging enabled by default in our
> >>> test suite so the exception trace is all I got. I am now repeatedly
> >>> running the test suite with the original flags (-Xms512M -Xmx512M)
> >>> and also added the following logging configuration:
> >>>
> >>> -Xlog:gc*=trace,heap*=trace,tlab*=off:stdout:time,pid,tid,level,tags
> >>>
> >>> As soon as I get another failure, I'll provide the full log file.
> >>> Please let me know if you need any other logs (i.e. whether I should
> >>> adjust my log configuration).
> >>
> >> I think these flags are fine.
> >>
> >> Since Erik and me strongly believe the issue is with the relevant G1
> >> code Erik mentioned we will reassign the bug to us (he said there is
> >> already a bug reported on it).
> >>
> >> Thanks a lot,
> >> Thomas
> >>
More information about the serviceability-dev
mailing list