JDK-8088114 : [WebView] JVM crash due to memory leak in WebView/Webkit
  • Type: Bug
  • Component: javafx
  • Sub-Component: web
  • Affected Version: 7u45
  • Priority: P2
  • Status: Resolved
  • Resolution: Duplicate
  • Submitted: 2014-01-10
  • Updated: 2015-06-26
  • Resolved: 2015-06-18
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9Resolved
Related Reports
Blocks :  
Duplicate :  
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Description
Note, this description was already given by my colleague Nicolai Kilian to RT-30354, which seems to describe the same issue but was put to resolved even though the issue can still be reproduced both on Java 1.7.0_45 as well as Java 8 build 120 (see Dierk K��nig's comment on RT-30354). As commenting didn't help we create a new issue.

For us this issue is not just critical but actually a blocker (!) as the WebView is needed for the core functionality of our customer project!



We're experiencing crashes in JavaFX web browser when using Google Maps.
It can be reproduced using this little project:

http://uploadir.com/uploads/9uitfqvw/downloads/new

From the README:

Application to test memory consumption behavior of Google Maps inside the embedded webkit browser of JavaFX.
It demonstrates that under Java 1.7.0_45, there is a memory leak related to JavaFX when using Google Maps with a lot of objects,
in contrast to loading the same HTML in Google Chrome.

** Test scenario **
When mapViewer.html is loaded, the Browser first navigates to Google Maps.
Then, in Javascript, 10'000 markers in and around Switzerland are created and displayed in Google Maps.
Finally, zooming in and out in the area of Switzerland is performed 40 times.

** Test environments **
All tests were performed under Windows 7 so far.
If mapViewer.html is opened in Google Chrome version 31.0.1650.63 m, the process memory consumption remains well below 300 MB.
However, if it is opened in the JavaFX application, Java 1.7.0_45, the process memory consumption increases from 200 MB to about 1500 MB.
At this point, the application crashes under Java 32 bit, but the memory leak is equally visible under Java 64 bit.

** How to reproduce **
- Install Java 1.7.0_45, JRE 32bit. http://www.oracle.com/technetwork/java/javase/downloads/jdk7-downloads-1880260.html
- Install Maven 3. http://maven.apache.org/download.cgi
- Edit googlemapsloader.js, edit the variable "var gMapsKey=". Insert your Google Maps API key into the quotes. How to get a key:
  https://developers.google.com/maps/documentation/javascript/tutorial?hl=fr#api_key
- Open mapViewer.html in Google Chrome and watch the working memory consumption, e.g. using Process Explorer under Windows.
- In the command line, navigate to the projects main directory and enter
  mvn clean jfx:jar <Return>
- Then, in Windows explorer, navigate to JFXMemoryTest\target\jfx\app and double-click JFXMemoryTests-1.0-SNAPSHOT-jfx.jar.
  Watch the growing working memory consumption, e.g. using Process Explorer under Windows.
Comments
The Webkit is leaking when using google maps only without any markers: just zooming in/out. Loading another page didn't release the memory.
29-04-2015

I seems that this issue was partially resolved: JDK 8u40b13 quite quickly eat the memory with this demo, i.e. grown up to ~6Gb in 10-20sec JDK 8u60b12 is growing its working set mem ~100M per minute
28-04-2015

It seems that this issue is not resolved by the new WebKit so we will need to evaluate it further.
13-03-2015

@kevin Well browsing Google Maps with JDK 9 x86 (build 1.9.0-ea-b53 ) on Windows 7 64bit, crashes jfxwebkit.dll after a while still, just tested it out now. # Problematic frame: # C [jfxwebkit.dll+0x7e57ff] Current thread (0x47c31800): JavaThread "JavaFX Application Thread" [_thread_in_native, id=5652, stack(0x4e310000,0x4e410000)] ... Stack: [0x4e310000,0x4e410000], sp=0x4e40dc84, free space=1015k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [jfxwebkit.dll+0x7e57ff] ... Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) J 4839 com.sun.webkit.WebPage.twkProcessMouseEvent(JIIIIIIIZZZZZF)Z (0 bytes) @ 0x028501f4 [0x02850150+0xa4] J 4838 C1 com.sun.webkit.WebPage.dispatchMouseEvent(Lcom/sun/webkit/event/WCMouseEvent;)Z (166 bytes) @ 0x02c129e0 [0x02c124c0+0x520] J 4864 C1 javafx.scene.web.WebView.processMouseEvent(Ljavafx/scene/input/MouseEvent;)V (184 bytes) @ 0x02af03e4 [0x02af0020+0x3c4] ...
13-03-2015

In JDK8 webview/webkit has a memory leak when zooming in and out of Google Maps. Can you check if this is fixed in JDK9? Thanks.
13-03-2015

We are proposing to backport the new webkit to 8u60 in RT-40055. The following JEP that is tracking this: http://openjdk.java.net/jeps/239
02-03-2015

@Kevin The b52 build of JDK 9 indeed seem to have solved the bug. However Java 9 is still a year away and here is no working workaround for this bug.
02-03-2015

The merged Webkit has been integrated and will be in 9-b52. We expect 9-b52 to address this bug.
27-02-2015

This bug is still present in early access releases of JDK 8u40 and JDK 9. As I understand we wont't be seeing a fix anytime soon. This makes the webView unusable for anything that has to do with maps.
27-02-2015

SQE is ok to defer from 8u40.
05-12-2014

I see no crash with WebView synced with WebKit trunk, that is awaited in 9. So, we need to defer it to 9 so far and then, hope, we will close it as no longer reproducible.
19-11-2014

Move to 8u40 - will get new webkit in 8u40
05-06-2014

SQE belives that this should be looked at as it affects both FX 8 and 2.2.
05-06-2014

We are sorry, but at this time we have no resources to work on WebView bugs for the 8u20 release. Unfortunately, we will have to defer them to 8u40.
23-05-2014

One problem is that the WebView does not cache any page content, it completely reloads it every time: -> WebView: Every response is 200 OK with full content / Firefox: Every second response is 304 Not Modified I dont't think it will solve the problem of this issue to implement caching (see https://javafx-jira.kenai.com/browse/RT-36252 ), but maybe it would help a little bit ;)
29-04-2014

This problem is reproducible in Java8 b132. Any HTML page that uses image (whether it's from CSS background or HTML img tag) will cause a memory leak. Loading an HTML page with no image element does not have this issue. The only way to reclaim memory is to terminate the app; continuous browsing will cause the memory usage to grow to a point where the computer is not responsive anymore.
03-04-2014

My current understanding is the following. Out of ~1GB RAM consumed, only about 100MB is allocated for image data. The main portion of RAM (800MB) is used by the JavaScript VM heap. The heap is splitted into 2 main parts: objectSpace and StorageSpace, which in turn consists of fromSpace, toSpace and the oversized blocks space. The latter consumes the majority of the heap space, and never decreases during the application execution. In Webkit code, GC'ing was rewritten significantly with http://trac.webkit.org/changeset/162017 So the upcoming sync with Webkit codebase could solve the issue.
26-02-2014

Using webview in a javafx leads to excessive memory usage based on my simple application of displaying a webview and navigate through different url . It consumes memory and never release it until my mac just stop been responsive. This can be see in Activity monitor app in Mac where each page navigation result in increase hefty memory usage. I notice that it just did not release memory use from previous page. I am using the latest java 8 rc on mac. To me is that WebView is barely usable due to what I believe to be memory leak.
25-02-2014

Memory profiling shows that a lot of instances of WCImageDecoderImpl remain alive as JNI global roots, consuming heap space for image data.
17-01-2014

Yes, it is still reproducible in jfx8. The memory consumed grows quickly up to ~1Gb and then the application crashes. BTW, a key is not necessary for Google Maps API v3 anymore.
17-01-2014

@Patrick: There is no release vehicle for any Java 7 update before JDK 8 ships in March. Also, if this problem is reproducible in Java 8, then we will need to fix it in an 8 update release. We can also consider fixing it in a 7 update release after the fix is available for 8, but in general we are only fixing bugs for 8, so you are encouraged to update to JDK 8 as soon as you can. @Leonid: can you determine whether this issue is still reproducible in 8?
14-01-2014

I'm glad this issue got priority "critical". What worries me is the fix version. Is there any chance that the fix (or a workaround) will be available for Java 7 too? Our release date is in mid March, the same as Java 8, so there will be no time to switch to and test on top of Java 8.
14-01-2014

Depending on where this is crashing, this may be related to RT-27803 but that bug is FX 2 (JDK 7) only, so this is probably a different bug.
11-01-2014