Something got changed at the new SDK and my code suddenly isn't working.
I created a new empty project and created only a UITableView in it.
I used the same code as i've been used to, except the compiler said that i do not need to use autorelease anymore, so i removed it.
Oh, and I replaced retain with strong as i was recommended.
When I run the app it shows the TableView like it should look, but the minute i touch anywhere on screen, like scrolling for example, it crashes with EXC_BAD_ACCESS error.
What do I miss??
You should post some more informations on where your program crashed! But I don't think the mentioned compiler warnings are the reason. You should have tried to run your project with the compiler by turning of ARC (automatic reference count) and see what happens. If you can go back, do that first.
Also maybe there went something wrong with the changes you made because of ARC . If you have not done the changes with the Xcode refactoring tool I recommend you doing so.
Therefor select in the Xcode Menu:
Edit > Refactor > Convert to Objectiv-C ARC...
It will go through your code and apply the changes. Apple recommends though that your project should work without crashes and warnings before using it.
Related
I waited until 6.0.1 to switch to Xcode 6. Upon opening one of my project, I noticed that the quick help view of a method or variable's documentation doesn't work anymore.
For example a simple:
/*! Value of the property. */
for a #property just causes Xcode to say 'Declared in' when trying to view the doc by option clicking on a use of the property somewhere in the code instead of displaying the documentation itself.
Cocoa's own classes doc still display fine and I can tell my documentation gets parsed as incorrectly naming a #param will still cause a warning.
Deleting all the stuff cached in ~/Library/Developer/Xcode/DerivedData fixed the issue.
I already asked this in the Apple Dev Forum but received no replies, so I'll try here.
I'm unsure if this is a bug or whether I've missed something since I'm still very new to programming.
I have multiple view controllers and have made multiple classes. I have set the custom class "bit" of each view controller to the revelent class. When I ctrl-drag anything from the view to the relevent class header, I get the usual pop-up. I fill in the info, press connect, and BAM. It does the same kind of error whether I choose "Outlet" or "Action" It worked in the previous Xcode but I'm not sure if I've forgotten something.
The view controller and class that I added with Xcode 4 is still working beatifully.
I've tried adding the image manually but all that gave me was a SIGBART error just trying to get to the view. Again, I may have missed something, but I don't think there's much to miss is there?
Any help would be appreciated.
Just to eliminate a few things... I've deleted derived data, restarted Xcode and done a "clean". That's all I can remember that I've done.
Problem solved:
When selecting the implementation file. When I looked in the File Inspector, I found that under "Target Membership", the app name wasn't ticked. I ticked it and it now works well.
Since I didn't need to do that in Xcode 4, I suspect in Xcode 5, it doesn't do that automatically. Maybe that's a bug? I don't know if it was deliberate by Apple, but I think I'll file a bug report anyway since It's a bit of a nuisance.
I'm attempting to use this approach, described by Marco Arment, for checking if a class exists before using it. With the correct settings, classes are automatically weak-linked when it's appropriate. As Marco describes, "you can safely subclass or have pointers to whatever you want (as long as you’re careful not to instantiate them when they’re not available)".
My app runs fine on iOS 5. I've followed the conditions mentioned at the link:
Base SDK is Latest iOS (iOS 5.1)
Deployment Target is iOS 4.0
Compiler for C/C++/Objective-C is Apple LLVM compiler 3.1 (also tried LLVM GCC 4.2)
Any time I reference NSMetadataQuery I'm making sure the class exists first:
if ([NSMetadataQuery class] != nil) …
Despite all this my app crashes immediately on launch if I try to run it on an iPod touch with iOS 4.2.1:
dyld: Symbol not found: _OBJC_CLASS_$_NSMetadataQuery
I've tried commenting out all the code any my app runs fine. As soon as I add back in a single reference to NSMetadataQuery, it crashes. I've even tried this:
if ([NSMetadataQuery class] != nil) NSLog(#"OK");
Simply including that line, and no other reference to NSMetadataQuery, crashes the app. Even more strange, checking for other iOS 5 classes doesn't cause any problems:
if ([UIDictationPhrase class] != nil) NSLog(#"OK");
That works fine, as expected.
I have been able to work around the problem using the uglier NSClassFromString() to make sure the class exists, but I'd love to know why the other approach isn't working.
I don't have an explanation to this but I ran into the same problem as you. No matter what I/you do, NSMetadataQuery just won't be weak linked...
Refer to this answer, which is really the best one in another question:
https://stackoverflow.com/a/8426591/129202
In short, other auto weak linking seems to work, it's just NSMetadataQuery* that you have to remove from source and replace with id. Instantiate the class with NSClassFromString() etc. No hiccups on other classes like UIDocument however so you can safely use those in the normal sweat free way.
NSMetadataQuery is available in iOS 5.0 and above, so any versions below that has no clue as to what it is. By merely using it in your code, the class name will be added to a symbol table and looked-up when the app launches.
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"];
}
}
After using Finder to make a copy of my project, the iPhone Simulator crashes giving me an NSInternalInconsistencyException error. I subsequently used Time Machine to restore the project before I made the copy, but am still getting the NSInternalInconsistencyException error.
This is a small homework assignment and re-creating it wouldn't be the end of the world. My big concern is that I don't understand something fundamental about how Xcode is working. Any illumination would be greatly appreciated.
Update
Apple identified the bug. The iPhone Simulator keeps the last-run version of the app onboard, and doesn't replace it with the copied/Time-Machine-Restored version that is in Run-and-Build. Deleting the app from the iPhone Simulator and performing a new Run-and-Build resolves the issue.
Sounds like a bug. Your source code files should be fine, so hopefully it's not a big deal to just create a new project and add those files so that you can get back to work. You might also want to report the issue to Apple, especially if you can make it happen again.