committed > max in MemoryMXBean#getHeapMemoryUsage()
Erik Helin
erik.helin at oracle.com
Thu Jul 19 14:57:25 UTC 2018
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