JDK-8087417 : Resource leak in WebView component
  • Type: Bug
  • Component: javafx
  • Sub-Component: web
  • Affected Version: 8u20,9
  • Priority: P4
  • Status: Closed
  • Resolution: Cannot Reproduce
  • Submitted: 2014-12-05
  • Updated: 2018-03-14
  • Resolved: 2018-03-14
Related Reports
Blocks :  
JDK-8096642 - Broken rendering and resource leak in WebView component
Duplicate :  
JDK-8135015 - Webview leaks resources
Description
See BugDB https://bug.oraclecorp.com/pls/bug/webbug_print.show?c_rptno=20003159 for detail.

This was split off of RT-39345 to track the resource leak issue described in that bug report.
Comments
Tested WebViewDemo.jar by loading "http://www.lazaworx.com/static/croatia2012/Trogir/index.html#P6219395.jpg" (and other thumbnails in this link) in webview with JDK 10+40 and issue is not reproducible. Hence closing this issue as Not reproducible.
14-03-2018
[~pmangal] Can you verify this issue with 8u182 / JDK 11 release ?
08-03-2018
As a P4 retargeted to 11. However you still can push a fix with "10" target till RDP2 in Jan 2018: http://mail.openjdk.java.net/pipermail/jdk-dev/2017-October/000085.html
02-11-2017
I can steadily reproduce the "Outstanding resource locks detected" problem with 8u40, but it seems it's gone in 8u60 (for this particular web app). We should probably keep the bug open due to the following: <<Debugging shows that it happens because instances of WCBufferedContext containing clip layers and created from native ImageBuffer constructor, don't ever get disposed. The fix plan is to force disposal of WCBufferedContext from within native ImageBuffer destructortor.>> Until we make sure that indeed reveals a memory issue (because, as I said, I can no longer reproduce it). However, I'm lowering the priority to Medium.
30-04-2015
not 8u60 regression, do we want to retarget to 9. Anton?
29-04-2015
The testcase from the BugDB bug intensively uses non-rect (path based) clips. Such clips are implemented as layers containing image buffer. So, stacking N path-based clips means allocation of N images than are never released. Debugging shows that it happens because instances of WCBufferedContext containing clip layers and created from native ImageBuffer constructor, don't ever get disposed. The fix plan is to force disposal of WCBufferedContext from within native ImageBuffer destructortor.
05-12-2014
Target to 8u60, although we will try to get this in for 8u40 (thus I added a critical watch label). @Leonid: please set a due date for this bug.
05-12-2014