Bug 1284948 - Using jdb triggers OOME on the debugged application
Using jdb triggers OOME on the debugged application
Status: ON_QA
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
Depends On:
Blocks: 1298243 1313485 1390370
  Show dependency treegraph
 
Reported: 2015-11-24 09:07 EST by Ingo Weiss
Modified: 2017-03-06 11:04 EST (History)
8 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:
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

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