Is it possible that a CADisplayLink gets called one or two more times even after being invalidated?
It looks that way to me, and this is causing me a problem because the target object is called where it's already gone so it crashes.
Thanks!
According to the docs, "The newly constructed display link retains the target." so it shouldn't crash in any case.
EDIT: Try setting the environment variables NSZombieEnabled=YES and NSDeallocateZombies=NO (the latter is the default, apparently), which may help debug the crash.
Related
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.
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've spent two days on this and I still can't find the cause of the crash.
I know it has something to do with trying to access an object that has been freed but I don't know which access or which object.
Whenever I google trying to find the source of EXC_BAD_ACCESS people suggest using NSZombies. The problem is when I enable zombies (either in xcode via environment variable or in instruments via ObjectAlloc properties) the program doesn't crash where it usually does and the zombies don't report anything (nothing shows up in logs and nothing is flagged in instruments). Is there something I'm missing with NSZombie?
I've tried utilizing some information from xcode's debugger and from ObjectAlloc in instruments but all the information is very cryptic and doesn't really help me.
I've set the debugger to stop on objective-c exceptions. When it does it this is the call stack shown:
0 objc_msgSend
1 ??
2 -[UITableViewCell removeFromSuperView]
3 -[UIView dealloc]
... etc ...
First of all, what's the deal with '1 ??' ? What do the question marks mean? Second of all how can I know where this was called in my code? All the operations stated are too generic (eg UIView dealloc, but which UIView? And where?).
Also when the exception occurs it points to assembly code which again, doesn't do me any good unless I was to spend hours trying to figure out what the code does. I know some assembly but there has to be a better way... right?
Is there any way I can get meaningful information as to what was the last line that ran in my code before the exception occurred?
I've tried sprinkling some NSLogs and breakpoints around but it doesn't help me much because the crash happens after I pop a view controller from a navigation controller. Everywhere I place breakpoints the breakpoints are reached fine (I can't find a point to break after the crash). It's only when I 'continue' in the debugger that the exception occurs. It's as if the crash happens outside of my code so I have no idea where to get a handle on it.
I've looked through my code and double checked that I adhere to all the memory management rules (at least to the best of my knowledge). I'm sure it's something very subtle but I can't seem to find it.
If anyone has any ideas how to find such bugs without NSZombie please share.
Thanks.
Well I found the problem. I had a custom table cell class in which I called [super dealloc] first in the dealloc method (rather than last). I guess I wrote this class in a hurry and didn't really think about it. I'm guessing something got released in the parent that the child needed for releasing?
So I don't have a real answer to my own question but basically I found the problem using a combination of ad-hoc code tracing and various debugging techniques (breakpoints, NSLogs, trying to decypher cryptic stack trace,etc).
Actually the main strategy that helped me was commenting out code bit by bit until I stripped down the problem area into as simple as it gets while still keeping the crash intact. This let me realize the problem wasn't where I thought it would be but in a more subtle area (eg in the dealloc method of a secondary class in this case).
I hope this can sort of help someone out. I'll leave this question unanswered for a bit incase someone has a more thorough debugging strategy without relying on NSZombies. Also if someone can clarify what those two question marks mean in the stack trace that would be helpful.
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.