We are looking into JavaFX 2.2 as a framework for building a desktop application. But before burning many developer hours we wanted to make sure that JavaFX is fit for the job, so we made a small stress test to see if it leaks resources. The test shows and hides a Stage, containing a Label and a Button, in a never ending loop. We would expect this to continue forever without problems, but after approx 15500 iterations we get this exception
java.lang.RuntimeException: could not create platform window
at com.sun.glass.ui.Window.<init>(Window.java:180)
at com.sun.glass.ui.win.WinWindow.<init>(WinWindow.java:20)
at com.sun.glass.ui.win.WinApplication.createWindow(WinApplication.java:97)
at com.sun.javafx.tk.quantum.WindowStage.initPlatformWindow(WindowStage.java:131)
at com.sun.javafx.tk.quantum.WindowStage.init(WindowStage.java:82)
at com.sun.javafx.tk.quantum.QuantumToolkit.createTKStage(QuantumToolkit.java:501)
at javafx.stage.Stage.impl_visibleChanging(Stage.java:928)
at javafx.stage.Window$10.invalidated(Window.java:689)
at javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:127)
at javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:161)
at javafx.stage.Window.setShowing(Window.java:782)
at javafx.stage.Window.show(Window.java:797)
at javafx.stage.Stage.show(Stage.java:229)
at leaktest.FXMLController.showHideDialog(FXMLController.java:58)
Our best guess is that show()/hide() on Stage leaks some resource, and dheapmon reveals that desktop heap memory is actually leaked during the test, but we don't hit the limit (20 MB on our test machine). GDI handle and USER handle limits are not the problem either since those handles are not leaked (according to Process explorer). Any suggestions to what causes the exception?
This was a memory leak in the window disposal code of JavaFX. The leak was fixed in JavaFX 2.2.40 as part of bug fix RT-26822 Win: Stage Exception:could not create platform window.
Related
I few days search the source on the memory leak in my software and at least found it.
So steps:
I create the GUI application, add image to the .qrc, create form in Qt Designer, add QPushButton there and in the styleSheet property write
#closeButton{ image: url(:/system/images/White/Close.png); }
(the button named as "closeButton")
Without style sheet that I add the program works fine, with style sheet - I receive memory leak.
So how to avoid memory leak in this case?
Objects that survive till the process termination aren't necessarily memory leaks, and the tool won't be able to tell you which ones are memory leaks and which aren't. Memory leaks are usually only the allocations that are made multiple times from the same program location, and never get freed. Even then, it may not always be the case. Leak detection requires a purpose-made test harness that repeats a series of operations that are supposed not to leave behind memory allocated at any given program location more than once. If you then notice that, with increasing number of operations, the number of memory blocks left behind increases, you likely have a real leak. Ideally, the test harness should take snapshots of allocated memory blocks after each "operation cycle", and flag the program locations that consistently leave stuff behind. The library should be able to capture a stack trace to give you the program location where the allocation was made. Otherwise it's useless in practice.
I'm very suspicious of code that deallocates all memory before process termination: usually it's just wasted time, and it prolongs system shutdown and is just bad UX. When the user hits the "Exit" button, make sure that data is safe (e.g. close sqlite files, save open documents - maybe just as "work in progress" that will be brought back the next time the application is used), and then call exit(0).
In general, leak detection takes a bit more than just using a library that gives you a list of memory blocks allocated at exit. The library is a tool, that you, a thinking, reasoning human developer must apply to the problem :) Just as a hammer won't be useful by banging it all over the place (unless you got lots of nails to hammer!), so won't be a "leak detector" library all by itself.
(it's a Sysinternal's-Process-Monitor-like system monitor program based on QT 5.7.0 which could monitor and record most behaviors of process in the system.
program view
memory usage
As you can see it cost 100MB+ memory when there are 30000+ events recorded.
and the memory usage could be easily increased to 1.0GB, even 2.0GB when there are more events, that's unacceptable in low performance machine. shall I save these events in sql database?
I use a QTableView with a custom model inherit from QAbstractTableModel attached to it, which displays only visible items. the memory issue is not caused by UI, since it cost so much memory even if I remove the tableview.
The issue occours after ca. 2 minutes passed (about 1800 times updated). TextViews simply stop to update with no reason, even if accelerometer updates are still working. Our team is working on multithreaded aplication where we have to update some UI control values on UI thread (thats problably the reason why the issue occours). We have spent amount of time trying to figure out what might be the problem and finally we have decited to report it as an issue. I have prepared some sample code based on accelerometer functionality, but in fact the same problem occours when we are trying to use other hadrware devices or sensors (e.g. bluetooth). Here is the link to the sample app repository:
https://mvvmlightbug.visualstudio.com/DefaultCollection/_git/MVVM%20Light%20bug#path=%2F&version=GBmaster&_a=contents
During debug process I've found out that Garbage Collector is somehow removing my bindings. It was because of WeakReference usage in MVVMLight for Android library. I've lust replaced all WeakReferences with object types and since then there is no more problem.
For MVVMLight creatrors: please ensure that WeakReferences are the best solution - you should rather replace them, because Android's GC is removing bindings with no reason.
I'm developing a mobile app using Flex and I have run into some problems using BlazeDS. Some users request a (relatively) pretty large amount of data from my server, which returns in about 2 seconds. The data consists of some pretty simple objects (Client, which has a name/phone/email, and a few other properties, some of which are other nested objects with more properties). The largest requests consist of no more than about 10,000 of these objects, which is only a few MB in size. The problem I am running into is that as soon as the server sends its response, the mobile screen locks up while the data is being processed. For 10,000 objects, this can take several minutes and sometimes even crash the device, and at best leave the user with a frozen screen the entire time. For the average user, it is at least 2-5 seconds of frozen screen. This is not only an issue for devices with limited capabilities. This also happens on my PC (i5 processor, 8GB RAM). From what I can tell, this downtime is taking place somewhere between when the device receives the response and when I can access the data. Setting a breakpoint on the first line of the following RemoteObject result handler has the screen lock up BEFORE it reaches the breakpoint:
protected function myResultHandler(event:ResultEvent):void
{
var result:ArrayCollection = event.result as ArrayCollection;
//Do other stuff here
}
I know very little about BlazeDS and AMF, so my only guess is that the freezing happens while the objects are being created on the device. Is there any way to speed up this process at all? Should I normally expect to see really poor performance like this? Any help would be greatly appreciated.
After a couple of hours digging around, I found the solution to my problem: On the server side, the objects I was sending had a ton of extraneous properties unrelated to the information I needed on the mobile app. In addition, there were helper methods on those classes in the form getMyHelper() which would attempt to generate a property on the Flex side. This resulted in a huge list of reference errors being thrown during the download since no properties with those names existed in the AS objects. I created stripped down 'lite' versions of the objects I needed sent across with no extra properties or methods. The massive lists now display nearly instantaneously after receiving the response from the server.
I spent hundreds of ours developing an Adobe AIR Application with Flex 4.0 and now I thought I should have finished, but after letting the application run for more than a few hours the UI-responsiveness begins to lack...
What I do:
My application uses custom chromes by setting backgroundImages with transparency to BorderContainers within Window-modules. I open up many different popups, which all are based on the Window-Class (not TitleWindow!) and created and closed dynamically in ActionScript. By using the Flex Profiler I certainly know, that the garbage collector destroys all the allocated ressources correctly, and the memory consumption does not rise with application uptime. Further the profiler shows me, that none of my methods occupate extensive cpu-time, so this also should be ok.
What is really interesting:
If I continously interact with the application (click buttons, write text,...) nothing happens and everything is fine, BUT if I do not interact with the application for several minutes and then come back - the UI-responsiveness is really poor!
Really poor means, that if I type some text into a TextInput-Control, I can watch every single letter being written with a delay of at least 1 second!
Has anyone experienced a similar situation, or someone who knows, what the problem could be?
My suggestion is, that after some activity the flash-player-runtime limits the cpu-usage of the AIR application, and doesn't give back full power when the user returns.
I tested the application with Flex 4.0, Flex 4.1, AIR 1.5, AIR 2.0 with Flash Player 9 and also Flash Player 10 running on Windows XP and Windows 7...
I have finally found the solution!
The new spark-components introduced with Flex 4 added a property called "backgroundFramerate" to the WindowedApplication-class. By default, this property is set to 1, which means that AIR automatically throttles the framerate when the main (!) application-window get's inactive. Unfortunately this framerate is used for the whole application, including all other window-instances which could be in the foreground and active!
After disabling the automatic framerate-throttling by setting the backgroundFramerate-property to -1 all the problems were gone!
Altough, I know, that instiating new window-derived objects to show popup-windows, I believe that this is a bug in the Flex 4 which is still not fixed.