I'm at a complete loss with a memory bug. This issue only happens on the device and not the simulator. It also only happens when the app is loaded for the first time on the device. If I close the app and relaunch it the issue does not preset itself. This is the error I'm getting
-[CFString retain]: message sent to deallocated instance 0xfd5a2f0
I've tried everything to attempt to figure out what the released string is. Please help me figure out what the released object is when running on the device and not the simulator! Thanks in advance!
UPDATE:
I still do not have a solution but I have confirmed the app will crash consistently on the line of code where I set a frame and the above error shows. If I comment this code out the app will pass this point but may crash at other strange spots. I can't even begin to determine where the crash is originating.
CGRect frame = CGRectMake(27, 96, 265.0, 50.0);
someAcct.frame = frame;
I'm so confused by this since this is not a string. Any ideas?
UPDATE 2: This issue is directly related to the NSUser Defaults being synchronized. This seems pretty random but this is causing the issue. Any Help?
UPDATE 3: The problem has been solved as of a week ago. This was in fact due to a string being inaccessible. A string was passed to a method, that method then did work and passed data to another method and so on. Until finally the data was to be written to user defaults and a local plist contained within the documents folder. All of a sudden the app would crash at very strange places like the above consistently even though those places had nothing to do with a string. I was baffled and after playing with it for a very long time I decided to head over to the .h file and go through each string one at a time by making sure each were synthesized in the .m file and that self.stringName was applied throughout the .m file. After spending an hour on this I finally found the string that was to blame and the issue is now resolved. Using self.stringName allows the memory to be found and avoids these obscure and highly confusing application crashes. Thanks to everyone for all of the suggestions and tips!
To help you with tracing it down, could you try putting NSLog at the start of your didFinishLaunching() method, somewhere in the middle and at the of the didFinishLaunching().
Then also could you push a NSLog in the viewDidLoad() of the first view controller your app shows. For example, if you're using a tab bar interface, then a NSLog in the first tab's root view controller.
You can use NSLog(#"step 1"), NSLog(#"step 2"), NSLog(#"step 3") ... to organise the output so you know where the code managed to reach up to before it crash, rather than NSLog(#"I am here").
The problem is of retain count. Refer mememory management and check u r not missing something.
Don't forget to turn on NSZombieEnabled.
One reason can be due to the iOS compatibility.Check if your device and the simulator are using the same iOS.Try working the simulator on the same version of OS as your device and change the release of the string accordingly.
Related
I came across the scenario where in if after moving the map immediately if I tap on back icon while the map has not fully loaded
The application crashes.
What I can understand is Since the loading is still in progress and I tap back the the application releases the controller but the google map loads asynchronously in NSRUNloop (not sure). So that might be the problem not sure though.
So does anybody know what can be the issue and is there any way to solve this issue?
Please comment if more description required.
It sounds like that when you close the view, the object that is the delegate for the completed map load has been deallocated, causing the crash with a bad access.
A good way to get to the bottom of these types of crashes is to use Instruments (part of the Xcode suite to tools) and go zombie hunting.
For anyone who is still searching for the answer
What exactly happening was that map view events were getting fired even if the controller was released causing a crash in the app.
So the solution is Before setting the value of objMKMapView to nil you need to set value of objMKMapView.delegate to nil.
I have some code that returns a struct containing 2 objects (declared as id).
When trying to use one of the objects I get an EXC_BAD_ACCESS and the app crashes. This only happens on the device (ipad) not in the simulator.
I have set NSZombieEnabled to YES, however no information is written to the console.
I don't know if it's a problem that I'm using a workspace in Xcode 4, one project for my app, and another that builds a library which is used in my app. The EXC_BAD_ACCESS is occurring in the second project, so I don't know if NSZombieEnabled will apply to the second project?
How do I solve this? Especially as I it only happens on the device (even goes as planned on the simulator), and it is in the second project?
EDIT: This is the method where the EXC_BAD_ACCESS occurs, on line 62, on sortRange.lower –
NSZombieEnabled only works on the simulator, not on the device, so it's probably hiding the problem. Run Product > Analyze (⇧⌘B) for clues. It's harder to say more without looking at the code. As Mihai says, your objects are probably over released, which is the most common cause of EXC_BAD_ACCESS.
It seems that one of your objects is autoreleased before you are trying to access it. As the iPad has less memory than the computer you are running it on it get's released faster so that's why it's not available. Try NSLog both objects just before the line you are getting the error and see wich one of them is the problem and than trace back to it's origin and retain it somehow. Also don't forget to release it after you are done using it. Some example code would be useful.
I know people here can help me with my problem in memory warnings on my app. I have multiple objects added to my Nib file, connected them to multiple IBOutlets and release these outlets on my viewDidUnload and dealloc method, I also set them to nil, but it still keeps on crashing after the "Received Memory Warning = Level 1" error message. I used NWPickerField for my objects in Nib files.
http://cocoacontrols.com/platforms/ios/controls/nwpickerfield
I just hope anyone here have tried using this :) thanks and Cheers!
If you're crashing when you receive the memory warning, that usually means that something gets deallocated, but it's pointer isn't set to nil, you try to access it, and Crash!
Errors like this can be hard to track down. A few types:
You can play around with XCode instruments (using Build&Profile in XCode 4) - specifically the Zombies one, which 'keeps dead objects around (as Zombies)', but let's you know when they get accessed.
Another useful one is a watchpoint. Once the simulator is running, right click a variable in console, and say 'Watch this address'. Then any line of code that causes a change to that memory location will cause a breakpoint when it occurs.
Another thing to try is just to run through all your ivars, inits, and deallocs, and make sure you really did get every case.
As you mentioned in your question.
I also set them to nil,
Do the proper memory clean up. by first calling release function or delete operator then assign the object with nil.
I am trying to access the UITextView delegates and have a problem
I have a UIViewController with the UITextViewDelegate protocol and a Nib containing the textView.
If I set the delegate inside viewDidLoad like "textView.delegate = self" and I touch the textView, the app crashes without logging errors.
If I start editing the textView with code like "[textView becomeFirstResponder]" all delegates get called.
When I set the delegate in the Nib creating a connection between the textView and the File's owner and deleting "textView.delegate = self" also no delegates get called.
What am I doing wrong here?
Regards,
Elias
It's not easy to help you without more description, posted code or a xib file.
You say application crashes without any logging errors - well, do you mean that there's no output in console's window ? That is normal, for an app that has crashed.
Anyway, you should be able to get the stack-trace to figure out where approximately the application has crashed. Open the debugger (⇧⌘Y), and see the position. That should give you an idea of what went wrong.
Here you can see an example of such debugger session (after EXC_BAD_CRASH):
First two lines doesn't give us much information, but later on we can see that application has crashed while loading user interface from a NIB file. Well, usually the only code that executes during such load are awakeFromNib methods - it's up to you to find a problem along those lines.
Often top of code's execution doesn't make any sense - for example you might see your ViewController method somewhere, but the top few function calls (those where the code crashed) are located in methods/classes which you never call in your code. In most cases that is a sign of wrong memory de-/allocation. What might happened is that you forgot to retain some of your objects, it has already been released, but you are still keeping reference (a pointer) to its memory. Because that memory has been in fact freed, another object took its place later on, usually some Apple's internal object you've never heard about. Later on your code tries to message your poor object but it sends a message to something completely different. BUMMER! That's how you get those crashes and strange stack traces.
To fix the kind of problem I've just described you can use Instruments and its Zombies instrument. Unfortunately you can't start Zombies from within Xcode, you need to start Instruments standalone, then choose the Zombies under iPhone Simulator/Memory, then Choose Target from the toolbar, you should see your application in there, or be able to navigate to it on filesystem.
What Zombies instrument does is that it never really frees memory after objects are deallocated. Instead, it will mutate those objects into NSZombie class. That class intercepts all calls to itself, and informs you when some code is trying to send a message to it.
This is how such Instruments session looks like (this is the same crash as seen in debugger above):
In the table you can see that we're trying to message UIScrollView that has already been deallocated. You can as well see the whole history of retain/release calls to this particular object. That way you can find a missing retain or wrong release/autorelease.
Remember - Zombies Instruments can only be used with Simulator, because there's not enough memory on the real device to keep all those memory blocks.
Hopefully I could help you with further analysis of your problem.
i populate uipicker's datasource from array built with sqlite database stored data. everythiongs works fine.. for a little while. after 6-7 spinnings, the picker freeze, and I get EXC_BAD_ACCESS. debugger indicates the program stopped in the main () function.
so, how could this happen? working for a while, and then, suddenly exit like that?
thanks
Somewhere in your application, you have over-released an object. When the application tries to access it again, very likely to release it (from an autorelease pool), it crashes. The problem may be completely unrelated to your picker.
Suggestion: try adding NSZombieEnabled YES to your executable's environment variables.