Debugging view controller transitions - objective-c

Is there a symbolic breakpoint or something that will trap the following warnings, so that the erroneous code can be more easily found?
Attempt to present <> on <> while a presentation or dismiss is in progress.
Trying to dismiss the presentation controller while transitioning already. (<>)
I don't have a specific problem to solve, just looking for an answer to this question, which could just be "no".
When these errors occur, how do you find out the present/dismiss call causing the problem and/or the present/dismiss that is in progress?

Maybe a little more context would help us answer your question ?
Are you using UIViewControllerAnimatedTransitioning ?
When are you having this issue happening ?
If you want to debug, you can use UINavigationControllerDelegate method for your convenience :
- navigationController:willShowViewController:animated: or
navigationController:animationControllerForOperation:fromViewController:toViewController:
If you're not already using it for your animation.

The best I've found so far is to run with Allocations instrumentation and "Record reference counts".
Then you can find the specific instances referenced in the logs by their address.
This will have recorded the stack traces when that object was created, presented, etc, as they all involve changes in reference count.

Related

Xcode: "Spurious Update" console warning?

I'm writing a pretty straightforward ObjC app. (The only minor complexity is that it uses an external library called Chilkat for some basic networking, but I don't think that that's relevant.)
Occasionally, my project spontaneously pops up this warning message:
May 14 01:24:01 Neovenator-2.local Project[22645] : void
CGSUpdateManager::log() const: conn 0x4b29b: spurious update.
And I have no idea how to handle or even interpret it. There's nothing in my project called CGSUpdateManager, and my project doesn't call a log() function anywhere. I can't even reliably reproduce it, but it's popped up often enough to raise my interest level.
Searches at both Google and here for the term "spurious update" reveals a lightly scattered set of conversation, but nothing relevant to my project. Meanwhile, a Google search for "CGSUpdateManager" reveals it's something to do with Swift, which I'm not using at all.
Can anyone help me understand what this means? Or should I just disregard it?
Make sure to call super in viewDidLoad, viewWillAppear and viewWillDisappear.
Sorry, my code with correct Highlight/indentation:
- (void)setNeedsDisplay
{
//#if 1 //TEST (suppose we are only called by us)
if(wvImageRep_DoRebuild)
//#endif
[super setNeedsDisplay]; // "spurious update" ?
}
It's an example (#see my full response), it helped me

Why is the value of variable different when using CCLog and using print in debug mode?

The strengthbar in my game doesn't work well after playing at least once of the level. So I wrote a method using CCLog to log out some variables and call this method in update: method. And I also set a breakpoint, when this problem appears it gets into debug mode of Xcode, then I use print to check the variables. However it appears that the values are different between using CCLog and using print command. Here's a screenshot that explains everything.
Here is my screenshot:
Does it have something to do with Multithreads(which I know nothing about)? I've checked the declaration of each logged variables, to make sure they're not declared several times using the same name.
OK, problem is solved.
When I wrote some delegate I used "Strong" which causes some retain cycles. Now I changed them all to Weak, and also changed the deployment settings to iOS 5 (or above).
The reason that the values of the variable are different is because in CCLog, the value belongs to the new scene, however there're more than one scene at the same time receiving my touches because of the retain cycles. Nothing wrong about XCode or Cocos2d, or CCBReader :-p
Hope this answer would help others. And many thanks to #Cy-4AH.
Because it was changed after it was printed. In the breakpoint you are lookng at new value.

NSDocument - how to prevent a document from being marked as updated automatically?

I have a cocoa app that allows the user to enter a query. I'm using an NSWebView with a TextArea HTML object. The problem is, as soon as I type anything into the textarea, my document gets marked as updated. Does anyone know of a way to prevent this?
I've verified that using a NSTextField does not reproduce this behaviour, but I specifically want to go with the HTML/TextArea for styling.
So basically: Can I make it so an NSDocument does not get marked as edited unless I manually call:
[document updateChangeCount: NSChangeDone];
This post on the Apple mailing list seems to match your problem exactly.
The solution suggested is to set a custom undo manager to the webview (sounds like hard work), however a quick-and-dirty hack looks to me like subclassing updateChangeCount and perverting things to your way of thinking.

Objective-C: Trying to use Apple's MultipleDetailView

I am working on trying to make a splitview based application. I am trying to use Apple's MultipleDetailView example code
http://developer.apple.com/library/ios/#samplecode/MultipleDetailViews/Introduction/Intro.html
I have never really used example code like this (I usually just atart from scratch). All i did was copy the code into the correct classes of my app, but when I try to run it on the simulator the app doesn't open.
I feel like I am maybe forgetting something obvious, since I didn't code it myself.
Thanks!
The usual debugging technique applies. Put a breakpoint somewhere early in the program -- the first line of main() for instance, and debug from there. Do you hit the breakpoint? If yes, move forward through the code until you find the line that causes the problem. If no, try to back up even further if you can, and also look for any clues as to what's going wrong. If the app is running at all, there should be some sort of error message in the console output.
"...the app doesn't open" doesn't tell us nearly enough to help you. Something like "the app delegate is instantiated, but it's window and splitViewController properties are nil" goes much further toward getting to the root of the problem.

EXC_BAD_ACCESS on animationForKey:

I'm trying to use a recent feature of the Scintilla component, which provides OSX-like text-highlighting effect (the yellow animated bouncing box), and I'm stuck with an error that pops up intermittently :
EXC_BAD_ACCESS
pointing to this particular line :
if (layerFindIndicator!=nil)
if ([layerFindIndicator animationForKey:#"animateFound"])
[layerFindIndicator removeAnimationForKey:#"animateFound"];
(the ifs are mine; just in case I caught the object layerFindIndicator being nil, or deallocated or whatever... Unfortunately, it doesn't help...)
layerFindIndicator is seemingly a subclass of CAGradientLayer. (You may see the full code for layerFindIndicator, here).
Since, I'm an absolute newbie to Quartz Core, could please give me any hint as to HOW this could be debugged?
Since, I'm an absolute newbie to Quartz Core, could please give me any hint as to HOW this could be debugged?
This doesn't have anything to do with QuartzCore specifically (at least, I hope not)—it's general this-object-has-been-killed-before-its-time-how-do-I-find-the-killer stuff.
In Xcode:
Edit your current scheme.
For the Profile action, set it to use the Debug build configuration.
Dismiss that and then hit the Profile command.
Xcode will build for that action and then launch Instruments.
Instruments will prompt you to choose a template; you want the Zombies template. Once you've chosen it, Instruments will create a trace document and run your application. Switch to your application (if it isn't already frontmost), then do whatever causes the crash.
If the crash really is a dead-object crash, Zombies will reveal it. You'll get a flag in Instruments's timeline saying something like “message sent to zombie object 0xd3c2b1a0”, and your program will probably exit shortly thereafter.
In that flag is a tiny little button that looks like this: ➲ except it'll be gray. Click on it.
That takes you to the history of that object (actually of that address, including any previous objects or other allocations that have started at that address). Show your Extended Detail Pane (the one that appears on the right showing a stack trace), then scroll down to the end and then move backward (upward) step by step through time, looking at releases and autoreleases, looking for the one that isn't balancing out the object's allocation or a retain.
The solution will probably involve one or more of:
Changing a property to be strong or weak rather than assign/unsafe_unretained
Adding a property where you previously did not strongly own an object
Rearchitecting some things, if it's not clear which of the above you need to do or if either one of them seems like a filthy hack
Switching to ARC to get weak properties and __weak instance variables (both of which get set to nil automatically when the referenced object dies) and to get local variables being implicitly initialized to nil
But it'll depend on what you find in Instruments. And, of course, there's the chance that your problem—the bad access—isn't a dead object at all and all of the above will not help you.
Try this:
if (layerFindIndicator!=nil){
if ([layerFindIndicator animationForKey:#"animateFound"]){
[layerFindIndicator removeAnimationForKey:#"animateFound"];
}
}
Also check to see if it is released else were.
EDIT:
Another thing I found was you didn't have an white space in the if. Your code should now look like this:
if (layerFindIndicator != nil){
if ([layerFindIndicator animationForKey:#"animateFound"]){
[layerFindIndicator removeAnimationForKey:#"animateFound"];
}
}