Can somebody can please verify that they can also reproduce that memory leak.
Create a new "Utility Application". Open the FlipsideView.xib and add a UITextview. Using the inspector, uncheck "Editable" and check "Detects Phone Number" and "Detects Links".
Run the app using the Leak instrument on an iPhone. Flip between the MainView and the FlipsideView a few times and observe the leak.
Thanks
I'm using 3.1.2
Your leak seems to be somewhere else, i tried what you say and no leaks show up when im using 3.1.2 .
However, i must add i did not connect the uitextview with IBOutlet as you did not mention it. If you are using
#property(nonatomic,retain) IBOutlet UITextView *....
it may cause a leak if you do not release your IBOutlet in dealloc.
Make sure you run Leaks against a real device, and not the simulator. I've found in the past that leaks were reported running my app against the simulator, but when I ran against a real device, those reported leaks went away.
Related
Having a strange issue with my app where the entire iOS device gets locked up and the only thing I can do is restart the device. I am not seeing any exceptions getting thrown, nor am I seeing any memory leaks in Instruments.
The app has a navigation controller with a main menu. I then push a viewcontroller that has a grid of images being loaded. If I go back and forth between the main menu and the grid the app will crash after ~15 times. However, it isn't just the app that's killed, it's the entire OS which is something I've never seen.
At first I thought I was leaking memory, but Leaks isn't showing anything. I'm playing around with Allocations and I'm seeing that the grid view controller allocation count just keeps going up. The app is using ARC, which I don't like that much because it's too "magical", but I assumed it would be cleaning up properly.
One thing that concerns me is that viewDidUnload nor dealloc is being called on my grid view controller after it popped from the nav controller, so I'm never explicitly cleaning up my images or killing network connections. I assume this is where the issue is at but I don't know when I should kill these because the usual places to clean up (ie. viewDidUnload, dealloc) aren't being called.
This is happening on iPhone and iPad both running 5.1 and I'm using the AFNetworking UIImageView category to load images.
Cheers,
I have a problem I can't locate clearly, maybe you can help me...
I have an iPad project, based on UINavigationController, most (but not all) of controllers inside are instances of UITableViewController, and everything works well...
Everything excepting that my application crashes randomly, sometimes after 10 minutes of use, sometimes after only 10 seconds...
It never crashes on the same view, never at the same time, making that difficult to reproduce.
In addition, it only seams to happen on device, I've never got this crash in the simulator.
The debugger doesn't help me very much, here is what it says:
-[UITableView autorelease]: message sent to deallocated instance 0x8e9800
And here is the call stack:
http://i.stack.imgur.com/JSCHx.png
Any idea ?
Thanks (and sorry for my english)
You're overreleasing a UITableView somewhere in your code. Are you calling release or autorelease on the UITableView inside one of your UITableViewControllers? You should only release objects that you 'own'. You get to own an object by using methods beginning with alloc, new, copy, or retain.
Please read the cocoa memory management guidelines for more info.
Useful links:
http://www.cocoadev.com/index.pl?MemoryManagement
http://www.cocoadev.com/index.pl?RulesOfThumb
At some point you are either releasing a UITableView instance that you do not own or you are failing to retain one at some point where you keep a reference to it (e.g. you store it in an ivar or a property declared assign rather than retain).
I have written about how to debug things like this on my blog:
http://loufranco.com/blog/files/Understanding-EXC_BAD_ACCESS.html
Basically, try these three things first:
Do a Build an Analyze and fix everything you see
Turn on Zombies, run your code -- it will tell you if you talk to dealloced objects
If that fails, try Debug Malloc, but that's way harder.
I apologize, after re-reading all my source code, I found ONE ViewController (I have around 20 ViewController), where I released an Outlet, in ViewDidUnload.
The reason that it crashed randomly is that I didn't understood well the mechanism of ViewDidUnload, it is called to release views (but not objects of controllers) when memory is low and view is not visible (ex: First ViewController of a NavigationController), and the views are re-loaded when the ViewController become visible again...
In simulator, memory is rarely an issue so ViewDidUnload is almost never called...
Problem fixed, thank you everyone for your help
To help with making sense of the trace, see iOS Debugging Magic (Technical Note TN2239) and Understanding and Analyzing iPhone OS Application Crash Reports (Technical Note TN2151).
Jeff
I have created UITextField in UITableViewCell in my app, and I receive strange memory leak with it.
When I launch my application and tap this UITextField - there is no problem with it. I can type text in English, no leaks at this moment.
But when I press globe button on a keyboard to switch to another language(for instance, Russian), I receive the memory leak in UIKeyboardInputManager, even if I don't type any text in non-english language.
Any ideas?
Tested both in simulator and iphone.
I would assume this is an issue with iOS, not even Apple is perfect. File a bug report with Apple.
http://bugreport.apple.com
Apple Developer Reference Library has a class reference for WebPreferences
I've searched SO, Dev Forums and Googled without any relevant results.
EXC_BAD_ACCESS signal is generated.
I can't find a crash report.. its happening on the simulator. The debugger is called, and I don't get a crash report.
EDIT
This is triggered when tapping a UITextField, leaving a UITextField or if a UITextField is set as first responder when loading a view (push on by a navigation controller).
It is not easy to reproduce. I can go for a hundred app-launch/debug cycles before it will happen again. And then it might happen 3 times in 5 launches.
I do have a thread list in the debugger that shows several references to WebPreferences.
You're on the right track if you are using NSZombie. EXEC_BAD_ACCESS is caused by accessing released objects.
It is normal for EXEC_BAD_ACCESS to "crash" in code paths that do not belong to you. Most likely your code created the over-released object.
The key part of using NSZombie is running the malloc_history on the command line. You'll get the call stack showing where the over-released object originated from. For example:
alt text http://static.benford.name/malloc_history.png
The screenshot shows my app crashing at [NSString stringByTrimmingCharactersInSet:] but that is certainly not who caused the crash.
I technique I use is to look at the earliest code path that you own. Most of the time the mistake lies there.
In this case, the object originated from the class [JTServiceHttpRequest requestFinished], in which I was not properly retaining a object.
If all else fails, go through all your code paths listed and verify your use of proper memory management rules.
My bet is that WebPreferences and UITextField behavior have nothing to do with the crash.
For any EXC_BAD_ACCESS errors, you are usually trying to send a message to a released object. The BEST way to track these down is use NSZombieEnabled.
This works by never actually releasing an object, but by wrapping it up as a "zombie" and setting a flag inside it that says it normally would have been released. This way, if you try to access it again, it still know what it was before you made the error, and with this little bit of information, you can usually backtrack to see what the issue was.
It especially helps in background threads when the Debugger sometimes craps out on any useful information.
VERY IMPORTANT TO NOTE however, is that you need to 100% make sure this is only in your debug code and not your distribution code. Because nothing is ever released, your app will leak and leak and leak. To remind me to do this, I put this log in my appdelegate:
if(getenv("NSZombieEnabled") || getenv("NSAutoreleaseFreedObjectCheckEnabled"))
NSLog(#"NSZombieEnabled/NSAutoreleaseFreedObjectCheckEnabled enabled!");
If you need help finding the exact line, Do a Build-and-Debug (CMD-Y) instead of a Build-and-Run (CMD-R). When the app crashes, the debugger will show you exactly which line and in combination with NSZombieEnabled, you should be able to find out exactly why.
The fact that it's crashing in _integerValueForKey: makes me strongly suspect that it's crashing on an over-released NSNumber. Over-releasing an NSNumber can lead to such bizarre crashes that it's almost humorous. Here's what happens:
You create a NSNumber for the integer "2"
The NSNumber class caches the NSNumber
You over-release it
The NSNumber class's cache now points to bad memory
Some completely unrelated piece of code creates an NSNumber for the integer "2"
The NSNumber class looks it up in its cache, and....
Bang
If you're running Snow Leopard, hit Cmd-Shift-A to let the analyzer look for memory management problems. Otherwise, go hunting in your use of NSNumbers.
agreed with previous responders about NSZombie. Most often this thing happens when you use your class as a delegate of a UITextView(or any else class) and also refer it in IBOutlet variable. when you leave your viewcontroller - it become deallocated. but if you didn't release IBOutlet variable in - (void) dealloc method - UITextView will still send calls to released delegate (your view controller).
Sounds more like an Auto-Release bug. You might be releasing something you don't "own" and the NSAutoRelease pool is running and trying to clean up something that was already released?
Did you release something you didn't "alloc"? For example, you wouldn't do:
NSString *test = #"testing";
[test release];
As this will cause the crash to happen when the Auto Release pool runs and attempts to release the NSString.
I encountered a weird behavior in memory just by displaying the default keyboard.
I've just created a project with an .xib file for testing purposes.
This .xib file has an UITextField element in it and it's connected in the .h via:
#property(nonatomic, retain) IBOutlet UITextField *sometext;
The .m has no changes but:
#synthesize sometext;
- (void)viewDidAppear:(BOOL)animated {
[someText becomeFirstResponder];
}
As you see it's very very simple.
The problem is that once the keyboard is shown, the memory allocated for it NEVER goes down.
I've tested this scenario in another project with the only difference of having two .xib files.
Standar pushViewController and popViewController calls are made. Instruments show an increase of 600kb in memory allocations [which are a lot more in the actual iPhone device].
All in all, hehehe. My question is:
How do I release the memory allocated for the keyboard?.
You don't. Is it a leak? If you are just looking at the Allocations, don't expect it to go back down.
EDIT:
Clarification - Object Allocations in Instruments will always go up. It won't go down. It doesn't show deallocations, just allocations...