Bug 1284948 - Using jdb triggers OOME on the debugged application
Using jdb triggers OOME on the debugged application
Status: VERIFIED
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: java-1.8.0-openjdk (Show other bugs)
7.0
x86_64 Linux
high Severity high
: rc
: ---
Assigned To: Severin Gehwolf
Lukas Zachar
: Reopened, ZStream
Depends On:
Blocks: 1298243 1313485 1390370 1442162
  Show dependency treegraph
 
Reported: 2015-11-24 09:07 EST by Ingo Weiss
Modified: 2017-05-05 09:47 EDT (History)
9 users (show)

See Also:
Fixed In Version: java-1.8.0-openjdk-1.8.0.121-2.b13.el7
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1442162 (view as bug list)
Environment:
Last Closed: 2016-06-06 12:15:49 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Test case (3.64 KB, application/zip)
2015-11-24 09:08 EST, Ingo Weiss
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Icedtea Bugzilla 3313 None None None 2017-02-17 01:35 EST
openjdk bug system JDK-8153711 None None None 2016-04-15 13:00 EDT

  None (edit)
Description Ingo Weiss 2015-11-24 09:07:06 EST
This bug seems quite similar to https://bugs.openjdk.java.net/browse/JDK-4858370 and can be reproduced on OpenJDK 1.7.0.91 and OpenJDK 1.8.0.65.

To reproduce this issue, run the attached test case. Once on JDB prompt run eval Main.dummy(arr) followed by cont. Running the class without attaching a debugger runs fine.
Comment 1 Ingo Weiss 2015-11-24 09:08 EST
Created attachment 1098224 [details]
Test case
Comment 2 Ingo Weiss 2015-11-24 09:08 EST
Created attachment 1098225 [details]
Proposed patch
Comment 3 Deepak Bhole 2015-11-24 10:31:59 EST
Assigning to Andrew to review/integrate the patch
Comment 4 Andrey Loskutov 2015-11-26 02:52:30 EST
This bug is not similar to https://bugs.openjdk.java.net/browse/JDK-4858370, it *is* this bug.

This is not related to the jdb alone, the jdb was used in the reproducer because the effect is easy to demonstrate by using jdb. Same effect happens if one debug JVM from Eclipse (using same API as jdb) and evaluates any methods there in the "Display" view. All objects and all arguments used for evaluation are leaked. Same effect happens also if we use JDWP API to get/set values in the debuggee JVM from our IDE code to reflect changes user made on test specifications.

This was the original trigger for this request, because using JDWP API causes OOM in the application while accessing "bigger" data objects or "root" objects holding references to many other objects. Since references to accessed objects are never released, application dies sooner or later with OOM.

While usually this could be treated as nasty but not that critical (restart the app and the problem is solved), the severity is critical for our application where the main use case is to allow continuous debugging of semiconductor chip tests. Restarting the application only because we leak memory is highly undesirable because the test initialization costs lot of time. Crashing with OOM while the chips are connected can leave system in unpredictable electrical state, causing hardware failures.
Comment 5 Andrew John Hughes 2015-11-26 15:10:44 EST
What is the origin of this patch? The issue has not been fixed in OpenJDK (invoker.c is unchanged all the way up to OpenJDK 9) so, for upstream OpenJDK, it will need to go to 9 first then all the way back to 8, 7 and 6. I ran the reproducer on 6, 7 and 8 and all throw an OutOfMemoryError after the cont invocation:

JDK: /usr/lib/jvm/icedtea-7
java version "1.7.0_91"
OpenJDK Runtime Environment (IcedTea 2.6.3) (Gentoo icedtea-7.2.6.3)
OpenJDK 64-Bit Server VM (build 24.91-b01, mixed mode)
Default execution without jdb:

Used: 440,536, free: 39,929,640, total: 40,370,176 
Used: 24,663,488, free: 15,706,688, total: 40,370,176 
Used: 286,496, free: 40,083,680, total: 40,370,176 
Used: 24,727,064, free: 15,643,112, total: 40,370,176 
Used: 285,584, free: 40,084,592, total: 40,370,176 
Used: 24,505,848, free: 15,864,328, total: 40,370,176 
Used: 285,584, free: 40,084,592, total: 40,370,176 
Used: 24,505,848, free: 15,864,328, total: 40,370,176 
Used: 285,584, free: 40,084,592, total: 40,370,176 
Used: 24,505,848, free: 15,864,328, total: 40,370,176 
Used: 285,584, free: 40,084,592, total: 40,370,176 
Used: 285,584, free: 40,084,592, total: 40,370,176 


After jdb starts, execute the commands below: 

eval Main.dummy(arr) 
cont 
... repeat two steps above until JVM terminates with OOM ... 


Starting same program with jdb now:

Listening for transport dt_socket at address: 8000
Set uncaught java.lang.Throwable
Set deferred uncaught java.lang.Throwable
Initializing jdb ...
*** Reading commands from /home/andrew/projects/openjdk/tests/OOMonDebug/.jdbrc
> 
VM Started: No frames on the current call stack

main[1] Deferring breakpoint Main:12.
It will be set after the class is loaded.
main[1] > > Set deferred breakpoint Main:12
Used: 881,304, free: 39,488,872, total: 40,370,176 
Used: 25,109,760, free: 15,260,416, total: 40,370,176 

Breakpoint hit: "thread=main", Main.main(), line=12 bci=25
12    			arr = null;

main[1] eval Main.dummy(arr)
Called dummy
 Main.dummy(arr) = <void value>
main[1] cont
> Used: 12,289,696, free: 28,080,480, total: 40,370,176 
java.lang.OutOfMemoryError: Java heap space
Dumping heap to java_pid27871.hprof ...
Heap dump file created [49067140 bytes in 0.141 secs]

Exception occurred: java.lang.OutOfMemoryError (uncaught)"thread=main", Main.main(), line=10 bci=18
10    			arr = new Main[3000000];

main[1] eval Main.dummy(arr)
Called dummy
 Main.dummy(arr) = <void value>
main[1] cont
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
	at Main.main(Main.java:10)
> 
The application exited
Comment 6 Andrey Loskutov 2015-11-27 04:18:21 EST
(In reply to Andrew John Hughes from comment #5)
> What is the origin of this patch? 

It is hand crafted by my colleague while he was tried to nail down the memory leak in our application :-)

The base for the patch was hg forest from http://hg.openjdk.java.net/jdk7u/jdk7u. The patch code itself was inspired by the proposed patch from https://bugs.openjdk.java.net/browse/JDK-4858370.

> The issue has not been fixed in OpenJDK
> (invoker.c is unchanged all the way up to OpenJDK 9) so, for upstream
> OpenJDK, it will need to go to 9 first then all the way back to 8, 7 and 6.
> I ran the reproducer on 6, 7 and 8 and all throw an OutOfMemoryError after
> the cont invocation:

Nice to see the reproducer works reliably for each Java release :-)
Comment 8 Andrew John Hughes 2015-12-04 11:50:46 EST
Ok, are you signatories of the Oracle Contributor Agreement? [0] I can't submit this patch upstream unless this is the case.

I'll need to rebase it on OpenJDK 9 and refactor it a little before sending it upstream.

[0] http://openjdk.java.net/contribute/
Comment 9 Andrey Loskutov 2015-12-04 12:03:08 EST
Neither me nor my colleague are signatories of the Oracle Contributor Agreement, so it will take some time. I guess you need it for the patch only, not for the reproducer test case?
Comment 10 Andrew John Hughes 2015-12-04 12:34:12 EST
Well, it depends if we intend to include the reproducer. In its current form, it seems unlikely as it can be automated as part of the existing OpenJDK regression tests.
Comment 11 Ingo Weiss 2015-12-16 02:23:21 EST
I am no signatory of the Oracle Contributor Agreement Andrew. Am I or Andrey required to be in this case?
Comment 14 Andrew John Hughes 2016-01-06 08:33:29 EST
(In reply to Ingo Weiss from comment #11)
> I am no signatory of the Oracle Contributor Agreement Andrew. Am I or Andrey
> required to be in this case?

The authors of the patch need to be signatories so it can be submitted to the OpenJDK project.

Ingo, as a Red Hat employee, you're covered by our corporate OCA (http://www.oracle.com/technetwork/community/oca-486395.html#r) but anyone else who contributed to the patch will need to sign, if they haven't already.
Comment 17 Ingo Weiss 2016-03-03 10:51:29 EST
Can this issue be investigated without the OCA concern if I remove the proposed patch from this bug report?
Comment 22 Severin Gehwolf 2016-03-21 13:52:56 EDT
I've asked for a review of my proposed patch for JDK 9 on upstream's serviceability-dev list:
http://mail.openjdk.java.net/pipermail/serviceability-dev/2016-March/019155.html
Comment 23 Severin Gehwolf 2016-03-23 05:32:28 EDT
This has been pushed to JDK 9 upstream[1]. I'll ask for an 8 backport shortly.

[1] http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/277d7584fa03
Comment 25 Severin Gehwolf 2016-03-29 08:39:42 EDT
Upstream JDK 8 backport request posted:
http://mail.openjdk.java.net/pipermail/jdk8u-dev/2016-March/005216.html
Comment 26 Severin Gehwolf 2016-03-30 04:09:45 EDT
This has been pushed to JDK 8 upstream[1]. I'll move on to a 7 backport soon.

[1] http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/4548a4525cb9
Comment 27 Andrey Loskutov 2016-03-30 04:51:09 EDT
(In reply to Severin Gehwolf from comment #26)
> This has been pushed to JDK 8 upstream[1].

Thanks! Can you please add a note here in which 1.8.x OpenJDK release the fix will be visible?
Comment 28 Andrew John Hughes 2016-03-30 12:26:00 EDT
A best guess would be u102, but Oracle haven't yet updated their documentation, following the u77 update: http://openjdk.java.net/projects/jdk8u/
Comment 29 Severin Gehwolf 2016-04-01 07:40:32 EDT
Upstream JDK 7 backport request posted:
http://mail.openjdk.java.net/pipermail/jdk7u-dev/2016-April/010499.html
Comment 33 Severin Gehwolf 2016-04-15 12:59:12 EDT
The JDK 9 fix got backed out due to test regressions. Same for JDK 8 and 7. The new upstream bug is JDK-8153711 and I've posted an updated patch for review here:
http://mail.openjdk.java.net/pipermail/serviceability-dev/2016-April/019410.html
Comment 34 Andrew John Hughes 2016-04-18 01:57:03 EDT
Removed from RPM.
Comment 36 RHEL Product and Program Management 2016-06-06 12:15:49 EDT
Development Management has reviewed and declined this request.
You may appeal this decision by reopening this request.
Comment 37 Andrey Loskutov 2016-06-06 12:18:47 EDT
(In reply to RHEL Product and Program Management from comment #36)
> Development Management has reviewed and declined this request.
> You may appeal this decision by reopening this request.

I guess this is related to the Java 7 backport only?
Comment 38 Deepak Bhole 2016-06-06 13:57:27 EDT
(In reply to Andrey Loskutov from comment #37)
> (In reply to RHEL Product and Program Management from comment #36)
> > Development Management has reviewed and declined this request.
> > You may appeal this decision by reopening this request.
> 
> I guess this is related to the Java 7 backport only?

Sorry, no we are deferring this to 7.4 given upstream slowness. I did not mean to have the bug closed. Re-opening. Severin is continuing to work with upstream as fast as possible.
Comment 39 Andrew John Hughes 2016-06-06 14:19:30 EDT
(In reply to Deepak Bhole from comment #38)
> (In reply to Andrey Loskutov from comment #37)
> > (In reply to RHEL Product and Program Management from comment #36)
> > > Development Management has reviewed and declined this request.
> > > You may appeal this decision by reopening this request.
> > 
> > I guess this is related to the Java 7 backport only?
> 
> Sorry, no we are deferring this to 7.4 given upstream slowness. I did not
> mean to have the bug closed. Re-opening. Severin is continuing to work with
> upstream as fast as possible.

There shouldn't be an issue with the 7 backport. Indeed, we got as far as having it in and ready to go, but then regressions were found with the original version of the patch in OpenJDK 9. We're waiting on those to be resolved upstream before backporting the updated version to 7 & 8.
Comment 41 Severin Gehwolf 2016-09-15 07:32:01 EDT
FYI, a fix for this (the redo) has been pushed to JDK 9 today:
http://hg.openjdk.java.net/jdk9/hs/jdk/rev/4c843eb35b8a
Comment 42 Andrey Loskutov 2016-09-15 08:34:03 EDT
(In reply to Severin Gehwolf from comment #41)
> FYI, a fix for this (the redo) has been pushed to JDK 9 today:
> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/4c843eb35b8a

Thanks! But I hope there are still plans to backport this to JDK 8?
Comment 43 Severin Gehwolf 2016-09-15 08:47:05 EDT
(In reply to Andrey Loskutov from comment #42)
> (In reply to Severin Gehwolf from comment #41)
> > FYI, a fix for this (the redo) has been pushed to JDK 9 today:
> > http://hg.openjdk.java.net/jdk9/hs/jdk/rev/4c843eb35b8a
> 
> Thanks! But I hope there are still plans to backport this to JDK 8?

The plan is to get it backported to 8 and then 7. In general, it's preferred to wait some time before starting the backport process into a stable release. That is to see whether a patch causes regressions elsewhere. Since the initial attempt was problematic already, I'll wait for a couple of over-night test cycles in 9 before asking for backports.
Comment 44 Andrey Loskutov 2016-09-15 08:57:02 EDT
(In reply to Severin Gehwolf from comment #43)
> The plan is to get it backported to 8 and then 7. 

In case it is relevant and can save your time, while our initial request was to backport this patch to 7, we've moved meanwhile to the 8 and so do not require backport to 7 anymore.

> In general, it's preferred
> to wait some time before starting the backport process into a stable
> release. That is to see whether a patch causes regressions elsewhere.

Sure.
Comment 45 Severin Gehwolf 2016-09-15 09:21:04 EDT
(In reply to Andrey Loskutov from comment #44)
> (In reply to Severin Gehwolf from comment #43)
> > The plan is to get it backported to 8 and then 7. 
> 
> In case it is relevant and can save your time, while our initial request was
> to backport this patch to 7, we've moved meanwhile to the 8 and so do not
> require backport to 7 anymore.

OK. Thanks for the heads-up.
Comment 50 Severin Gehwolf 2016-09-16 04:16:51 EDT
Resetting component to JDK 8 as per comment 44.
Comment 51 Severin Gehwolf 2016-10-10 11:47:53 EDT
So far no regressions showed up in JDK 9. JDK 8 backport requested upstream today:
http://mail.openjdk.java.net/pipermail/jdk8u-dev/2016-October/006002.html
Comment 53 Andrew John Hughes 2016-10-11 19:21:21 EDT
Patch backported to 8u upstream:

http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/3243d893b0b2

I'll add it to the RPM once we have the ACKs.

Are any more changes required for it to work with 7u?
Comment 54 Severin Gehwolf 2016-10-12 13:13:28 EDT
(In reply to Andrew John Hughes from comment #53)
> Are any more changes required for it to work with 7u?

No. The JDK 8 patch will work.
Comment 57 Andrew John Hughes 2017-01-12 00:33:06 EST
Seems to have been pushed back to 8u152 (January 2018???)

https://bugs.openjdk.java.net/browse/JDK-8153711
Comment 65 Andrey Loskutov 2017-04-12 03:06:37 EDT
(In reply to Andrew John Hughes from comment #57)
> Seems to have been pushed back to 8u152 (January 2018???)
> 
> https://bugs.openjdk.java.net/browse/JDK-8153711


> Fixed In Version: java-1.8.0-openjdk-1.8.0.121-2.b13.el7

@Andrew, Severin: is the issue now fixed in openJDK or not? The two comments above seem to contradict each other. Thanks!
Comment 66 Severin Gehwolf 2017-04-12 05:01:33 EDT
(In reply to Andrey Loskutov from comment #65)
> (In reply to Andrew John Hughes from comment #57)
> > Seems to have been pushed back to 8u152 (January 2018???)
> > 
> > https://bugs.openjdk.java.net/browse/JDK-8153711
> 
> 
> > Fixed In Version: java-1.8.0-openjdk-1.8.0.121-2.b13.el7
> 
> @Andrew, Severin: is the issue now fixed in openJDK or not? The two comments
> above seem to contradict each other. Thanks!

It's been fixed in upstream JDK 8 for a while now. The fix is scheduled to be included in RHEL 7.4 for java-1.8.0-openjdk (no guarantees, though).

Incidentally, JDK 7, specifically - java-1.7.0-openjdk-1.7.0.131-2.6.9.0.el7_3 - should have the patch too, since it's IcedTea 2.6.9 based[1]. That package should have been released already.

[1] http://blog.fuseyism.com/index.php/2017/02/14/security-icedtea-2-6-9-for-openjdk-7-released/
Comment 67 Andrey Loskutov 2017-04-12 05:35:51 EDT
(In reply to Severin Gehwolf from comment #66)
> It's been fixed in upstream JDK 8 for a while now. The fix is scheduled to
> be included in RHEL 7.4 for java-1.8.0-openjdk (no guarantees, though).

Thanks for fast response! Since we are on 7.2 and don't plan to move to 7.4 in the near future, we don't want to wait for RHEL 7.4. 

Can you please explain me - is there a java-1.8.0-openjdk rpm package available (provided by RH) containing the fix? Which minimum version of java-1.8.0-openjdk should we try to get the fix?
Comment 68 Andrey Loskutov 2017-04-12 05:46:27 EDT
To be more precise, I see today only 
1) https://access.redhat.com/downloads/content/java-1.8.0-openjdk/1.8.0.121-0.b13.el7_3/x86_64/fd431d51/package available for RHEL 7.3 
and 
2) https://access.redhat.com/downloads/content/java-1.8.0-openjdk/1.8.0.121-1.b13.el6/x86_64/fd431d51/package available for RHEL 6.x. 

Are those builds containing the fix for this bug, and which of them can be used on RHEL 7.2?
Comment 69 Severin Gehwolf 2017-04-12 08:20:09 EDT
There is no generally available java-1.8.0-openjdk package with the fix yet. If there was, this bug would have a status of CLOSED ERRATA.
Comment 71 Andrey Loskutov 2017-04-12 08:27:12 EDT
(In reply to Severin Gehwolf from comment #69)
> There is no generally available java-1.8.0-openjdk package with the fix yet.
> If there was, this bug would have a status of CLOSED ERRATA.

Severin, thanks again, but this was not the question. I *have* access to the RH network and *could* use packages mentioned above, but the questions are: 1) do they contain the fix and 2) can they be used on RHEL 7.2?
Comment 72 Severin Gehwolf 2017-04-12 09:41:16 EDT
(In reply to Andrey Loskutov from comment #71)
> (In reply to Severin Gehwolf from comment #69)
> > There is no generally available java-1.8.0-openjdk package with the fix yet.
> > If there was, this bug would have a status of CLOSED ERRATA.
> 
> Severin, thanks again, but this was not the question. I *have* access to the
> RH network and *could* use packages mentioned above, but the questions are:
> 1) do they contain the fix 

java-1.8.0-openjdk-1.8.0.121-2.b13.el7 and newer have the fix. If you are able to get those builds, then be aware those are unofficial builds. They'll still have to go through our testing machinery. I've verified that java-1.8.0-openjdk-1.8.0.121-2.b13.el7 and better pass the upstream OomDebugTest. That's about as good as it gets at this point.

> and 2) can they be used on RHEL 7.2?

Not sure what answer you are looking for. It's not recommended. All I can say is a) you'd be using non-released builds b) you'd run newer builds on an older version of RHEL. I.e. 7.4 build on 7.2 RHEL. You can use them, but you'd be sort of on your own. Neither of a) or b) are recommended practices.
Comment 73 Andrey Loskutov 2017-04-12 09:51:35 EDT
(In reply to Severin Gehwolf from comment #72)
> still have to go through our testing machinery. I've verified that
> java-1.8.0-openjdk-1.8.0.121-2.b13.el7 and better pass the upstream
> OomDebugTest. That's about as good as it gets at this point.

Thanks!

> > and 2) can they be used on RHEL 7.2?
> 
> Not sure what answer you are looking for. It's not recommended. All I can
> say is a) you'd be using non-released builds b) you'd run newer builds on an
> older version of RHEL. I.e. 7.4 build on 7.2 RHEL. You can use them, but
> you'd be sort of on your own. Neither of a) or b) are recommended practices.

A-ha, good to know. Do you know if a build for RHEL 7.2 is planned, or we are deemed to use not supported rpm (if we can install it at all) in order to get the fix? In case you need an official case number, it is CASE 01543682.
Comment 74 Severin Gehwolf 2017-04-12 10:33:53 EDT
(In reply to Andrey Loskutov from comment #73)
> > > and 2) can they be used on RHEL 7.2?
> > 
> > Not sure what answer you are looking for. It's not recommended. All I can
> > say is a) you'd be using non-released builds b) you'd run newer builds on an
> > older version of RHEL. I.e. 7.4 build on 7.2 RHEL. You can use them, but
> > you'd be sort of on your own. Neither of a) or b) are recommended practices.
> 
> A-ha, good to know. Do you know if a build for RHEL 7.2 is planned, or we
> are deemed to use not supported rpm (if we can install it at all) in order
> to get the fix? In case you need an official case number, it is CASE
> 01543682.

7.3 is current RHEL 7. 7.4 is an upcoming release which will have the fix. There are no builds planned for 7.3 (let alone 7.2). Perhaps there are options to get the fix through the support channel faster, but that's beyond me.
Comment 75 Deepak Bhole 2017-04-12 11:30:44 EDT
Hi Andrey, the 7.3 RPMs should work on 7.2 as well in theory and are worth a try.
Comment 77 Andrey Loskutov 2017-04-12 11:32:25 EDT
(In reply to Deepak Bhole from comment #75)
> Hi Andrey, the 7.3 RPMs should work on 7.2 as well in theory and are worth a
> try.

Thanks, I will try it.
Comment 78 Deepak Bhole 2017-04-12 11:40:01 EDT
Great! Requesting z-stream
Comment 79 Andrey Loskutov 2017-04-13 11:21:39 EDT
(In reply to Severin Gehwolf from comment #72)
> (In reply to Andrey Loskutov from comment #71)
> > (In reply to Severin Gehwolf from comment #69)
> > > There is no generally available java-1.8.0-openjdk package with the fix yet.
> > > If there was, this bug would have a status of CLOSED ERRATA.
> > 
> > Severin, thanks again, but this was not the question. I *have* access to the
> > RH network and *could* use packages mentioned above, but the questions are:
> > 1) do they contain the fix 
> 
> java-1.8.0-openjdk-1.8.0.121-2.b13.el7 and newer have the fix.

Unfortunately I still see the regression (just tried with the attached test).

rpm -qa | grep java-1.8.0-openjdk
java-1.8.0-openjdk-headless-1.8.0.121-0.b13.el7_3.x86_64
java-1.8.0-openjdk-debug-1.8.0.121-0.b13.el7_3.x86_64
java-1.8.0-openjdk-src-1.8.0.121-0.b13.el7_3.x86_64
java-1.8.0-openjdk-headless-debug-1.8.0.121-0.b13.el7_3.x86_64
java-1.8.0-openjdk-1.8.0.121-0.b13.el7_3.x86_64
java-1.8.0-openjdk-src-debug-1.8.0.121-0.b13.el7_3.x86_64
java-1.8.0-openjdk-devel-1.8.0.121-0.b13.el7_3.x86_64
java-1.8.0-openjdk-debuginfo-1.8.0.121-0.b13.el7_3.x86_64

and still see that the memory is not freed up :
$ ./runMainWithJdb.sh

openjdk version "1.8.0_121"
OpenJDK Runtime Environment (build 1.8.0_121-b13)
OpenJDK 64-Bit Server VM (build 25.121-b13, mixed mode)
Default execution without jdb:

Used: 435,840, free: 39,934,336, total: 40,370,176 
Used: 24,645,608, free: 15,724,568, total: 40,370,176 
Used: 269,936, free: 40,100,240, total: 40,370,176 
Used: 24,479,712, free: 15,890,464, total: 40,370,176 
Used: 269,336, free: 40,100,840, total: 40,370,176 
Used: 24,479,112, free: 15,891,064, total: 40,370,176 
Used: 269,336, free: 40,100,840, total: 40,370,176 
Used: 24,479,112, free: 15,891,064, total: 40,370,176 
Used: 269,336, free: 40,100,840, total: 40,370,176 
Used: 24,479,112, free: 15,891,064, total: 40,370,176 
Used: 269,336, free: 40,100,840, total: 40,370,176 
Used: 269,336, free: 40,100,840, total: 40,370,176 

After jdb starts, execute the commands below: 

eval Main.dummy(arr) 
cont 
... repeat two steps above until JVM terminates with OOM ... 

Starting same program with jdb now:

Listening for transport dt_socket at address: 8000
Set uncaught java.lang.Throwable
Set deferred uncaught java.lang.Throwable
Initializing jdb ...
*** Reading commands from /xxx/.jdbrc

VM Started: > No frames on the current call stack

main[1] Deferring breakpoint Main:12.
It will be set after the class is loaded.
main[1] > > Set deferred breakpoint Main:12
Used: 645,576, free: 39,724,600, total: 40,370,176 
Used: 24,855,344, free: 15,514,832, total: 40,370,176 

Breakpoint hit: "thread=main", Main.main(), line=12 bci=25
12                      arr = null;

main[1] eval Main.dummy(arr)
Called dummy
 Main.dummy(arr) = <void value>
main[1] cont
> Used: 12,274,088, free: 28,096,088, total: 40,370,176 
java.lang.OutOfMemoryError: Java heap space
Dumping heap to java_pid11061.hprof ...
Heap dump file created [48897181 bytes in 0.052 secs]

Exception occurred: java.lang.OutOfMemoryError (uncaught)"thread=main", Main.main(), line=10 bci=18
10                      arr = new Main[3000000];

main[1] exit
Exception in thread "main" Listening for transport dt_socket at address: 8000
java.lang.OutOfMemoryError: Java heap space
        at Main.main(Main.java:10)
Comment 80 Deepak Bhole 2017-04-13 11:57:58 EDT
(In reply to Andrey Loskutov from comment #79)
> (In reply to Severin Gehwolf from comment #72)
> > (In reply to Andrey Loskutov from comment #71)
> > > (In reply to Severin Gehwolf from comment #69)
> > > > There is no generally available java-1.8.0-openjdk package with the fix yet.
> > > > If there was, this bug would have a status of CLOSED ERRATA.
> > > 
> > > Severin, thanks again, but this was not the question. I *have* access to the
> > > RH network and *could* use packages mentioned above, but the questions are:
> > > 1) do they contain the fix 
> > 
> > java-1.8.0-openjdk-1.8.0.121-2.b13.el7 and newer have the fix.
> 
> Unfortunately I still see the regression (just tried with the attached test).
> 

Hi Andrey, I am terribly sorry, I was unclear in my original comment (and misinformed about the status of this bug). 

The fix is not yet 7.3 yet. Once we have approval on the request Andrew made this morning, we will have a clone of this bug for 7.3.z through which we will fix this as soon as we can.

Once again, I apologize for the error on my part.

Note You need to log in before you can comment on or make changes to this bug.