I have VB.NET application in which one of the form has IE control in it, the application starts initially with memory size consumed around 9 MBs, but when IE form is launched, the memory consumed rises to 27 MB, and when that form is closed, the memory reduces merely by 3-4 MBs, so why memory allocated to IEFrame is not de-allocated automatically? is there any work around to solve this issue? if possible, launching the form as a separate process would be helpful.
If you make sure to dispose the form properly, the garbage collector should free up that memory eventually. Running the IE control in a separate process should not be necessary.
However, if you are using IE 7, you might want to read this question about memory leaks.
Why not just put that form in a separate application if this is an issue? There are plenty of ways you can pass whatever data between the two apps.
The still allocated memory might not be an issue at all. If you have sufficient available memory in the computer the .NET Garbage Collector will not run to clean up. Only when you need the memory the GC will kick in.
If you want to make sure it is a leak you could do the following:
Make sure you have no references to the form in any way.
Call GC.Collect()
See if the memory is still claimed
Do not put the GC.Collect() in the final build; it's just to make sure you are not hunting ghosts.
Related
I'm still fighting with memory leak. Using improved MemoryDiagnosticsHelper, i added possibility to make datastamps to see immediate memory cunsumption.
Problem starts at full app: i have a pivot with 3 items, 2 of them containing list of 10-20 objects (with possibility to jump to item details). Memory diagnostic shows, that it consumes about 50Mb of memory. After jumping to detail page and returning to pivot, memory consumption easily grows to 70Mb.
At first, i moved list to separate app. Without style, it takes 15 Mbs. I didnt check yet, but i assume, 2 lists in pivot would take about 20Mbs, because dlls are already loaded.
So, i decided to go deeper into app loading stage.
At the InitializePhoneApplication(), it takes 7 Mb.
At the CompleteInitializePhoneApplication(), it takes 8.5 Mb with empty ViewModelLocator, or 10.5 Mb with all viewmodels. Quite large, but i have 30-40 dataservices and 40-50 viewmodels. So let it be, i'd feel myself pretty ok, if it would not grow anymore.
At the first page's OnNavigatedTo(), it takes almost the same, kinda 10.7 Mb with all VMs, that's ok.
???
No profit. Seriously, what happens next? I cant see, what exactly is going on next, but MemoryDiagnosticsHelper says, that memory consumption jumps to 30 Mbs. Why? All dlls and VMs are already loaded. I'm just loading a very empty page, totally white.
Profiler (running in release mode, of course), is also helpless. It just shows growth in memory consumption, but it happens in non-managed memory. It annoys alot, really.
Ok, lets make question more clean. What happens next, when app is initialized (passed initialization, and viewmodel loaded and attached, and page passed OnNavigatedTo())?
EDIT 1: in the night, i got and idea, that the only weak part in my app (at least, that master-detail pages) is MVVMLight's EventToCommand. Almost first article in google is http://atomaras.wordpress.com/2012/04/23/solving-mvvmlights-eventtocommand-memory-leak-wp7/ Anybody knows, if it is alreasy fixed? I checked MvvmLight's blog, and looking like Laurent is working on installer for now. That pushes me to idea, that this leak should be already solved, isnt it?
EDIT 2: i see 2 solutions for leaking problem: either to use fix from the link above, or call commands from the codebehind. Or use another MVVM lib.
References.
I expected them to be loaded smoothier, during first stages of app init. Also, now it is clear, why profiler said that there's not that much managed code in the memory.
I've recently converted my iOS project to ARC. I have two targets in my project. One is the application itself, and the other is a set of GHUnit tests. I have approximately 200 tests that do quite a lot of work in terms of creating and modifying Core Data objects. The Core Data store used by the tests is an in memory store, and is thrown away once the tests are finished (i.e. it is not persisted anywhere).
When my tests have been running a while (they never reach the exact same point before the error is thrown, but it is always around the same tests) the application crashes with an EXC_BAD_ACCESS (Code=2, address=...)
The output in the console is as follows:
I've followed the instructions here in this answer, and set my main.m file of the GHUnit target to use the -fno-objc-arc compiler flag, but that doesn't seem to have helped.
I don't really understand what these errors mean, and searching for them doesn't seem to have helped. My only guess is that I am running out of memory, but I'm not sure why or how, considering ARC should be releasing objects for me.
I'd really appreciate any help anyone can give me to fix this! If you have any questions just leave me a comment and I will get back to you asap!
Thanks!
Chris,
First, As you have a memory exhaustion problem, you should look at your tests running under the Instruments allocation tool. Remember to turn on VM automatic snapshots. Then you should mark the heap multiple times as the tests execute.
Second, while this may be related to ARC, it quite possibly isn't. In general, ARC apps, because they can automatically release objects sooner, have a smaller footprint than MRR apps. The move to a new compiler with different options may just be uncovering a pre-existing problem.
Third, because you are using an in-memory database, my first test would be to just change it to a SQLite DB. It can have a much smaller footprint. (While you may choose to return to in-memory DBs later, we're trying to find the cause of your memory exhaustion. An in-memory DB can use a lot of RAM. Hence, lets take is out of the equation.
Once you've done the 1st and 3rd tasks above, please report back your results.
Andrew
Well, that question may sound silly, but...
When I run my app in analyze mode or with instruments I get no possible (analyze mode) or memory (instruments) leaks.
Does it mean that my app is 100% memory leaks free ?
No. For one thing, you'd have to run every possible execution path/state sequence in your app to definitively say that there are no leaks by simple testing. More importantly, true memory leaks, where you don't release memory but no longer have a reference to it are all the leaks instrument is able to detect.
However, those are not the only similar problem you can create. You can also easily not discard data that you no longer actually need, causing memory to build up. This isn't a true leak, as you still have a reference to the data in question, it's just that you haven't released it and gotten rid of your reference to it.
You can still find this kind of problem using the allocations instrument. It won't explicitly flag problems, but it will allow you to see if you're allocating lots of memory that you don't later release. On iOS in particular, it's important to make sure that you give up allocated memory when you no longer need it, or your app's memory usage will grow until the OS terminates your app.
That really depends on how well you tested it with leaks but keep in mind that as hard as Leaks tries its not bulletproof, though if you do a through job you can be reasonably sure about your app. Don't forget to also use instruments other than leaks, the allocations tool is useful in picking up on abandoned memory which just Leaks won't point out to you but can be just as troublesome.
Your app does not run when you analyze, instead the static analyzer looks at your code. Regarding the instruments, check that your profile configuration (in edit scheme) is set to debug. Otherwise your app will be stripped out of symbols and the leaks instrument won't work.
you can assume it is in the best state now in which it could be.
From what experience I have programming whenever a program has a problem it crashes, whether it is from an unhanded exception or a piece of code that should have been checked for errors, but was not and threw one. What would cause a program to completely freeze a system to the point of requiring a restart.
Edit: Thanks for the answers. As for the language and OS this question was inspired by me playing Fallout and the game freezing twice in an hour causing me to have to restart the xbox, so I am guessing c++.
A million different things. The most common that come to mind are:
Spawning too many threads or processes, which drowns the OS scheduler.
Gobbling too much RAM, which puts the memory manager into page-fault hell.
In a Dotnet/Java type environment its quite difficult to seize a system up, because the Runtime keeps you code at a distance from the OS.
Closer to the metal say C or C++, Assembly etc you have to play fair with the rest of the system - If you dont have it already grab a copy of Petzold and observe/experiment yourself with the amount of 'boilerplate' code to get a single Window running...
Even closer, down at the driver level all sorts of things can happen...
There are number of reasons, being internal or external that leads to deadlocked application, more general case is when something is being asked for by a program but is not given that leads to infinite waiting, the practical example to this is, a program writes some text to a file, but when it is about to open a file for writing, same file is opened by any other application, so the requesting app will wait (freeze in some cases if not coded properly) until it gets exclusive control of the file.
And a critical freeze that leads to restarting the system is when the file which is asked for is something which very important for the OS. However, you may not need to restart the system in order to get it back to normal, unless the program which was frozen is written in a language that produces native binary, i.e. C/C++ to be precise. So if application is written in a language which works with the concept of managed code, like any .NET language, it will not need a system restart to get things back to normal.
page faults, trying to access inaccessible data or memory(acces violation), incompatible data types etc.
I am working with a free app that calculates grades for norwegian high school students. The different subjects are stored in a sqlite database. Everything works fine, except for one thing: If i close the app and restart quickly (faster than, say, one second), it crashes. Also, this only happens if I close the app in specific circumstances involving selecting/checking subjects in a UITableView (the changes are immediately stored in the database). Anyway if I wait for more than one second before restarting the app, it never crashes.
The error is not traced in any way in the console window.
Instruments has found some memory leaks in my app, but they are very small (16 bytes). I presume that is not the reason for the crash (but I will try to stop the leaks). I have also tried deleting and reinstalling the app, and turning the iPod/iPhone on and off. No change...
I understand that I cannot ask anyone to find the error in the extensive code of my app. My questions to you guys are:
Have any of you experienced similar errors? Related to sqlite?
Do you think App store will reject the app because of this?
Does anyone have any idea where to start looking for the error?
I am very thankful for any response!
When you say "it crashes," what is the actual error you get in the stack on the phone? Is it an actual crash, or are you getting a "failed to launch in time error?"
On iPhone, it's possible for an app's main thread to terminate while still running background nondetached threads. In this sense, despite all the claims that you cannot run in the background, you actually can... for a few seconds. When the main thread terminates, you go back to Springboard, and eventually the OS will kill your process if it doesn't terminate on its own. Do you manage any of your sqlite work on a background thread? Do you create any nondetached threads (this generally requires pthreads, so if you don't know, you probably aren't, but sqlite might; check in Instruments).
It's possible that your last instance still has a lock on your database, and that your re-launch doesn't react well to that lock. Do you have proper error handling around your open?