JDK-8094930 : Memory-Leak in Media Components
  • Type: Bug
  • Component: javafx
  • Sub-Component: media
  • Affected Version: 7u10,7u40,7u51,8
  • Priority: P3
  • Status: Closed
  • Resolution: Won't Fix
  • Submitted: 2013-02-13
  • Updated: 2015-06-12
  • Resolved: 2015-06-08
Related Reports
Blocks :  
JDK-8093636 - [media] Native memory leaking until nio.Buffers are GC'ed
Blocks :  
JDK-8096534 - [media] Long mp4 files (duration > 12hrs) are rejected by the media player.
Relates :  
JDK-8101978 - Add explicit dispose() method to MediaPlayer
Relates :  
JDK-8115891 - JavaFx MediaView hangs when I used large video files
Description
If we load many files in the application and calling seek() by using slider, as the no of files encreases the performanance of the application drops accordinlgy and the memory graph of the OS shows the encresing ratio of the memory.Looks loke JavaFx memory leak in media issue.
Comments
No plans to fix. Reopen or file a new issue if there is a concern. Any new issue aught to be reproduced with JDK 8.
08-06-2015
SQE OK to defer it to PSU15_03
09-02-2015
15_02 defer request, justification: No cycles to address for JDK 7u or 8u at this time. I will discuss this bug with the owner and define a resolution plan. It's likely we will close the 7u/2.2.x part of this as will not fix, but we may choose to do something for >= JDK 8
05-02-2015
Repeat, 2.2.80 does not fix the issue
09-12-2014
I found details of the issue reported on github for a framework that uses javafx. I hope it will be useful. https://github.com/caprica/vlcj-javafx/issues/2
08-08-2014
in the JDK8 there is same issue. In Windows 8 there isn't problem
07-07-2014
Correcting the fixVersion to 2.2.80, since this is reported against JDK7
17-06-2014
I tried everything and do not see an end
01-06-2014
This is part of my code : public void esegui(){ nextFileIndex = (nextFileIndex + 1) % videoFiles.size(); playerNew = new MediaPlayer(new Media(videoFiles.get(nextFileIndex).toString())); mediaView.setMediaPlayer(playerNew); playerNew.play(); playerNew.setOnEndOfMedia(new Runnable() { @Override public void run() { playerNew.stop(); playerNew.dispose(); playerNew = null; mediaView.setMediaPlayer(null); System.gc(); esegui(); } }); } but find no any change
20-05-2014
Anton, I tried System.gc() as well but find no any change, and System.gc() call make my application slow as well.
20-05-2014
One more idea is to call System.gc() to have a chance for DirectBufers to release their native memory.
20-05-2014
Try it, but dont change
20-05-2014
Akex, try to call MediaPlayer.dispose() at the end of each cycle.
19-05-2014
I have similar problem. you can read here ( http://www.java-forums.org/javafx/86731-javafx-memory-consumption-2.html ) to understand the problem in detail. There are also screen VisualVM. Or here ( https://community.oracle.com/thread/3560507 ) to quickly understand. in windows 8 I do not have these problems Also, do you know if mine is a known issue? Thanks
19-05-2014
We currently have no plans to fix it in 8u20
05-05-2014
Anton: can you reproduce the issue, and if so, do you plan to fix it for 8u20?
02-05-2014
In that case, I am reopening the bug to let Anton (or Kirill) comment.
15-03-2014
Hi Kevin, I am adding my QA comment hope this will be helpful for you. Here it is: import a video, and use seek while scroll, it will perform fairly well. However, if you continue to use the system, making edits into the Edit List, importing more videos, and editing with those, the performance of Seek While Scroll will start to degrade. Even just leaving the system sitting idle with an open project and coming back to it later can cause the performance to drop. Very noticeable on both platforms. Thanks & Regards
14-03-2014
OK, thanks. I misunderstood. In that case we are still in need of a test case to reproduce this issue (RT-28379).
13-03-2014
No Kevin with SR(3-8203950181) is not related to this case(RT-28379). The SR (3-8203950181) is for JIRA RT-34751. You can consider the production build of jdk 7U51 on which it can reproducible. Thanks,
13-03-2014
Anton: since you are working on the issue described in the SR (which has the FX shadow bug RT-34751), I have assigned this bug to you as well. Rahul: can you confirm that the test program you provided as part of that bug report will reproduce the memory leak?
13-03-2014
OK, thanks. I found the Bug using the SR number you provided.
13-03-2014
Hi Kevin, Thanks for quick reply. I has test with jdk_7u51 and also the build provided by Oracle support team javafx-sdk2.2.51-ea-windows-i586 with SR(3-8203950181). Thanks & Regards Rahul K Sharma
13-03-2014
Bugs that are resolved/fixed in a release should never be reopened. However, in this case the "Fixed" resolution was incorrect (should have been closed as a "Duplicate") so a reopen is OK as long as you have a test case that reproduces the bug. In the absence of such a test case, I am marking this bug as incomplete. Please also provide the JDK version that you are running.
13-03-2014
Sorry for delayed response. Reactivating this case is reproducible for our QA. I think this is not related to dispose() of media file as this is coming on seeking slider with more no of videos in the source and edit list. it also comes with large media files.please have a look. Thanks & Regards,
13-03-2014
This issue was resolved as part of RT-28817.
03-07-2013