I have a application that updates every X min. In the update routine, it calls multiple qx classes that are singletons with the getInstance() method. Is that something that would be causing a slow memory leak?
Note: Firefox v18 and IE8 (the only version I've tested with) will crash after about 24-30 hours of the application running, but for some reason Chrome v25 seems to do alright. Here is the site I'm referring to: preview.weather.gov/edd
This shouldn't be the cause of your memory leaks. The implementation of getInstance() within qooxdoo (and per definition) is very simple. As general rule of thumb try to call dispose() on qooxdoo objects you don't need anymore.
Also have a look at the manual (this may be outdated):
http://manual.qooxdoo.org/2.1.1/pages/development/memory_management.html#finding-memory-leaks
http://qooxdoo.org/docs/general/snippets#support_for_finding_potential_memory_leaks
Related
I have got CefSharp 3 with NuGet, and apparently it initializes as soon as the application starts debugging. My question is, how do I set the cachepath to Cef now that CefSharp 3 starts on its own and doesn't allow manual initialization.
Stopping it and trying to Initalize, isn't allowed neither.
Manual initialization is allowed and even encouraged. The automatic initialization is only a fallback as lots of new users struggled to get up and running quickly.
Simply call Cef.Initialize before you create the first ChromiumWebBrowser instance. This call needs to be made on the main application thread (typically the UI thread).
See a basic example at https://github.com/cefsharp/CefSharp.MinimalExample/blob/master/CefSharp.MinimalExample.WinForms/Program.cs#L15
The app is using my library which works using threads to do some operation; also it uses SIP VOIP library (obviously it is using threads). GUI is bound to interfaces of both libraries.
I noticed a weird behavior of my app. Usually it works just fine but sometimes after some time (3-5 minutes) it suddenly closes.
It is too irregular to debug it or diagnose.
Anyone had that kind of problem? Any idea what could be the reason for that?
I would recommend you add an application level error handler so that you can log any errors that are occuring that you might be missing. It is as simple as
Application.Current.DispatcherUnhandledException += HandleApplicationException;
Here is an MSDN article that describes it:
http://msdn.microsoft.com/en-us/library/system.windows.application.dispatcherunhandledexception.aspx
I've run into a few OutOfMemoryExceptions with my C#/WPF application and I'm running into some confusing data while attempting to profile the memory usage.
When the app is typically running, Windows Task Manager shows the memory usage as somewhere around 34 MB (bounces around slightly as objects are created and garbage collected). When I run memory profiling applications such as CLR Profiler and dotTrace Memory, they show the total memory usage at around 1.2 MB.
Why this huge discrepancy? What does Task Manager see that these profilers do not?
UPDATE: I added some diag code to my application to print out various memory information every so often via the Process class.
While running my app, I set up a rule in DebugDiag to perform a memory dump in the event of an exception. I forced an exception and the memory dump occurred. At this point, the memory usage of my app (as shown by task manager) jumped from 32 MB to 145 MB and remained there.
You can see this jump in the table below (WorkingSet64). I'm still trying to make sense of all the types of memory info provided by the Process class. How would an external application make the working set of my app grow like this?
Link to data table here.
Using some of the diagnostics tools suggested here, plus the ANTS memory profiler (which is so money) I found the source of the leak.
WPF Storyboard animations leak under .NET 3.5
The WPF BitmapEffect class can cause leaks. The alternative "Effect" class fixes the leak. Link, Link
XAML Merged ResourceDictionaries can cause leak. Link, Link
The "Working Set" memory footprint of an application (memory shown by task manager) is not a good indication of your process' footprint. Outside applications can influence this. Link
The memory profiling tools helped me find that the leaks were mostly in unmanaged code, which made it a real pain to track down. Dealing with these leaks, plus a better understanding of Windows memory (private vs working set) cleared things up.
Prcess Explorer and VMMap, both part of the Sysinternals Suite by Mark Russinovich.
I am using the SL unit test framework for tests (http://code.msdn.microsoft.com/silverlightut). My code is heavily client-server communications dependant, and I access the GUI dispatcher in several places to make sure important data is only accessed on a single thread (ie. the GUI thread).
This dispatcher seems unavailable in the unit tests - I have tried using Deployment.Current.Dispatcher and even created an instance of a blank control to try use its own dispatcher, but both don't work. The code inside of Dispatcher.BeginInvoke() just never executes, even if I include a Thread.Sleep afterwards.
I had to add references to System.Deployment and other testing libraries for Deployment.Current.Dispatcher to work.
It works fine now.
I have this global mouse hook setup in a DLL that watches for mouse gestures.
Everything works perfectly but with a hook set for WH_MOUSE_LL which is a low-level hook and one that doesn't need to be in an external injectable DLL.
Once I switch - to the more suitable one would say - WH_MOUSE mouse hook, everything falls apart. Once I click outside my main application (the one that installs the hook), the hook gets corrupted - ::UnhookWindowsHookEx will fail.
I only found this guy saying at experts exchange:
"No way, at least under Windows XP +
SVP2 WH_MOUSE won't go global, you
must use WH_MOUSE_LL instead."
I setup the hooks correctly: in a DLL using a shared data section, posting and not sending messages from the hook proceduce.
Why has this changed? And why is not documented? Anyone encountered this? Thanks!
BTW: I've reverse engineered a bit the popular StrokeIt application and it uses a combination of WH_GETMESSAGE and WH_MOUSE hooks and still works on XP/Vista...
Not sure if this would go better as a comment, but here goes:
I believe according to MSDN WH_MOUSE is supported at thread level or global.
As you pointed out yourself there are a bunch of apps using it.
So my guess is your specific implementation of the global WH_MOUSE has an issue that needs to be debugged and fixed. When you say that "the hook gets corrupted", what exactly happens? Does the hooked app crash? Could you attach a debugger to the app that you expect mouse events from and check what really crashes in your hook?
It's news to me that a global WH_MOUSE hook is no longer supported, since i have a few apps that use it and they continue to work on XP, Vista, and Windows 7.
How are you setting up the hook? you should be able to do SetWindowsHookEx(WH_MOUSE, my_mouse_callback, g_hinstance, NULL).
The only thing i can think of is that the callback function is taking too long, in which case Windows might remove the hook, or it isn't properly calling CallNextHookEx.