I'm loading a couple of large csv files when my app loads for the first time and this works fine on the simulator but when running on my phone it crashes about 30% through with the message 'Program received signal "0"' which implies a memory crash. However, when I put a breakpoint in the didReceiveMemoryWarning event it doesn't seem to be called.
Am I missing anything or will the program normally shut down without the event being called?
If you're loading the file in a synchronous call on your app's main thread, that would prevent it from receiving other messages (such as memory warnings) before the synchronous call completes. Try making loading the CSV files an asynchronous task. (A good starting point would be reading up on NSOperation.) That will allow your app to receive memory warnings during the loading process.
What's happen if you try loading small csv instead. If it work fine then your csv is too large and cause memory issue. If so you may have to read the csv file chunk by chunk and release the memory of the old one before reading the new one.
Related
I search how find my problem.
In my application for iPad when i treat data i have an increase memory and never release that memory, i try instruments leaks memory but that not find memory leaks (i try with profile and analyze).
So my question is they have an other instrument for find memory leaks or other methods?
Thanks in advance for your consideration.
P.S : I don't post code cause that concerned a big part of my code but the part where memory increase is a part where i download from a FTP some zip files (based on SimpleFTPSample from Apple Doc) i unzip this files (with framework minizip) this zip files contains some images and XML files i parse this XML files (around 7200 XML files and 35 000 images files saved) i saved some information (issue of parsing) in data base and that its. If you need part of my code for help me ask me.
Make sure if you have Zombies turned off in Scheme:Diagnostics. With Zombies on no memory is ever deleted. Testing for memory leakage should always be done with Zombies off.
This usually happens when you keep the objects in a datastructure (NSDictionary, NSArray, eg), even after you don't need them anymore. Check with Instruments' Allocations which objects are accumulated, and check in your code where you keep instances of those objects.
Another cause could be long-running threads.
If the loading and parsing you mentioned are done in a single thread that takes a long time, then you may need to do #autoreleasepool in a loop somewhere to force temporary objects to be cleaned up regularly.
It might also be no problem at all. You say you load a lot of images. Images are by default cached by iOS, and only released when necessary to clean up memory. If Instruments "Trace Highlights" shows a lot of memory usage, but "Allocations" doesn't, then this is likely the cause.
I have followed Cocoa is my girl friend's tutorial here, which is based on a subclass of NSOperation to fetch and load big number of records in a background thread, but in my case I have several thousands of records which take 1-2 minutes of continuous loading from a remote web service. The app have web service proxy classes generated using SudzC. There is no memory leaks detected. The problem occurs after the app finishes loading and saving this huge number of records into sqlite database (using core data), I notice that this import/save operation consumes so much memory, i.e. after this operation finishes, I use the app features for couple minutes (opening table views, writing text, etc ...), then i will see a crash that happens due to low memory, if I didn't include the import/save operation the app works fine without any low memory crash!
does anybody have a clue for this problem ?
thanks in advance.
I am currently programming a iPhone-app for my maturity research. But there is an behavior I don't understand: Sometimes when i compile my project there is:
Thread 1: Program received signal : "EXC_BAD_ACCESS".
But when I compile the same code a second, or a third time the code just runs fine and i can't get why. I use some MonteCarloSimulation but when it fails it fails executing one of the first 100 simulations. But when every thing runs fine it executes 1000000 simulations without an error.. Really strange isn't it?
Do you have any idea? Can this be an issue of Xcode or arc?
All other things just work perfect.
Do you have to get any further information? I can also send you my code as an email.
This usually means you're trying to access an object that has already been deallocated.
In order to debug these things, Objective C uses something called "NSZombie" that will keep those objects around so you can at least see what it is that's trying to be called. See this question for some details on how to use it.
This is typically caused by accessing some memory that's been corrupted, chances are you have a reference to an object which has been deleted. A lot of the time you may find that the memory where the object was located has not yet been overwritten, so when you attempt to access that memory your data is still intact and there is no problem, hence it working some of the time.
Another scenario would be that you've got some code writing into memory using a bad reference, so you're writing into an area you shouldn't be. Depending on the memory layout when the program starts, this could have no effect some of the time but cause something catastrophic at other times.
I've got an app that caches a pretty decent amount of data in memory after parsing a csv file, and also displays an MKMapView. After scrolling across the country from one end to the other in the MKMapView, the app inevitably gives me one or more:
Received memory warning. Level=1
Received memory warning. Level=2
and finally crashes due to low memory. I've been trying to figure out a means of managing either the memory of MKMapView or my own data (which comes from a csv file - the csv file needs to be written to frequently, so I'd like to keep it in memory in some fashion or other if possible, unless there is a better means of handling the issue.
Any ideas?
Use instruments to determine how much memory the cached CSV is taking vs the MKMapView. If the CSV is the problem, then look at storing it using CoreData or sqlite.
I'm working on catching a seriously insidious bug that's happening in my code. The problem is, the bug is completely random and can happen either 9 minutes into the application's runtime or 30 minutes. I've gone ahead and added the fabulous PLCrashReporter to my project (http://code.google.com/p/plcrashreporter) and that works fine for trivial bugs. Also, when I'm in doubt, I will navigate to the crash logs found in ~/Library/Logs/CrashReporter/MobileDevice/ and run symbolicatecrash on the crash log. This + GDB will eventually catch any bug, except for the one I'm facing now.
Apparently the nature of this bug is preventing even Apple's crash logs to be properly written to storage. This shows when I sync my iPhone or iPod Touch with iTunes and run symbolicatecrash on my app:
sf$ symbolicatecrash foo.crash
No crash report version in foo.crash at /usr/local/bin/symbolicatecrash line 741.
It might be that my application is not leaving a crash report at all, and exiting due to memory issues. I do indeed see the applicationWillTerminate: executing my NSLog statement before exiting, in my App Delegate. However, after running the application through ObjectAlloc, my application never reaches > 2.08MB of usage. Although if I'm reading the results proper, I did allocate over 28MB of memory throughout the entire duration of my test run.
Thanks again for everything.
A couple of suggestions:
Make sure that you're not actually calling exit(), returning from main(), or otherwise cleanly exiting anywhere in your code. If your application is just quitting, and not crashing, that obviously won't leave a log.
I think that running the system very rapidly out of memory can sometimes cause your application to crash without leaving a crash log. Run it under Instruments and see what the memory usage over time looks like.
If you have a set of steps that "often" reproduces the problem, try running it under the debugger and poking at it until it does crash. That might be a half-hour well-spent.
Having eliminated the obvious/easy, it's on to the more-obscure. Chances are that you're corrupting your heap or stack somewhere along the way, via a buffer overrun, re-using an invalid pointer, etc, etc. Here are some things to try:
Try running with NSZombieEnabled=YES in the environment variables. This will help you find re-use of freed objects. It does have an enormous impact on memory usage though, so it may not be applicable for everyone. Here's an Apple article dealing with NSZombie (among other things).
When running in the iPhone Simulator, use the "Simulate Memory Warning" item in the Hardware menu to force a low-memory condition - this can flush out bugs in that code, which otherwise runs at unpredictable times.
Last but not least, do a search through your code for everywhere that you use low-level C memory manipulation functions - malloc, calloc, realloc, memcpy, strcpy,strncpy, etc - and make absolutely sure that the buffer sizes are appropriate.