XCode 4.2 on OSX 10.7.1 (Lion) Crashing/Locking Up all the time. Anyone Know how to fix? - ios

This should not create any Issues with the NDA as I am not asking anyone to reveal any functionality of the application, I have asked on the Developer Forums, but They dont have the user base or the response speed of StackOverflow.
I have been working with XCode for a while now. And other then these issues, I REALLY LIKE the new xcode. I will (when these issues are resolved) recommend this application to all iOS/OSX developers.
Anyhow.
I am currently developing iOS applications. And am Running this setup on Mac OSX 10.7.1 (Lion)
Issue 1:
If I use the Interface builder it will first of all stay open even after I navigate away from it and it is no longer visible or to my knowledge "running". After a while it will consume more then 4 gigs of active memory. I will have the activity monitor open and Will eventually have less than 20megs left of free memory. I upgraded my MacMini to 8 Gigs of memory and at this point it will get down to about 200 Megs of memory left and will eventually release the memory that IB had held onto. If I do not open IB in XCode 4 it tends to use a lot less memory. (adding 8 gigs of memory makes this memory leak a lot less of a problem)
Issue 2: (MOST ANNOYING, HOPING FOR A FIX TO THIS ONE MOST)
This one only currently happens on one of the Three machines I code on. And what happens is while programming if I [Run] the app it will work for a while. Then at some point through the process it will begin to Lock Up when I press Run or Command-R. If I save the code file and run. It will not lock up. However if I forget to save, It will not only lock up. But will force me to terminate the XCode app, and Subsequently Recode everything that I had edited since the last save and the Application Run. This is by far the most annoying bug I have encountered this far.
Issue 3:
This bug happens more and more often the longer the application and operating system has been running. Running into the iPad will give me a number of Errors including "Unable to Connect to Debugger" or "Finished Successfully" among others. But the important part of this issue is that the application will never get sent to the iOS device. It will compile and say it finished. But there will be a error in the output pane.
I hope others have encountered these errors and Hopefully there is a quick fix with config files or something that will make development a lot more convenient. Thanks to anyone for resolution to any of these issues.....
EDIT
I finally received an email from apple support. I have emailed them off a Capture from XCode 4 and will hopefully hear something from them. Or maybe they will just release a new beta. Either way I hope to get this resolved asap.

For issue #2 you might want to try auto-saving your code before runs. See XCODE auto save code when build and run? instructions. Not sure if these instructions will work for 4.2 but you get the idea.

I had issues with my Xcode 4.2 install crashing initially. Re-running the installer over the already installed Xcode 4.2 fixed them. Obviously I don't know what the underlying issue with the install was, but although the first install reported installation was successful, obviously it wasn't. Perhaps worth trying.
When a newer version of Xcode 4.2 becomes available to you (cough), you might want to see whether installing that one fixes the problem. Perhaps given the issues, you should try uninstalling the previous version first rather than installing over the top?

Do you use multiple windows? They are anathema to Xcode 4. If you persist in your heresy, it may corrupt some files, and slow itself down. You will see a lot of beachballing, and it will be in some sort of GC.
You can work around this by deleting a workspace-specific file hidden inside your project. (I will have to look up which one, if this describes your case.)

With the new Beta GM Release they have seemingly fixed the issue with the Hanging.
Thanks for the Answers. Ill +1 anyone who helped but ultimately it was apple that fixed the issue.... For now

Related

IBDesignablesAgentCocoaTouch and Interface Builder Cocoa Touch Tool are eating my CPU

Does anyone know what these two: IBDesignablesAgentCocoaTouch and Interface Builder Cocoa Touch Tool are doing ?
Every time I have Xcode open these two are using so much CPU that my fans are at max speed.
I am using Xcode 9 beta 5 at the moment. Not sure if these all started with beta 5 or beta 4.
Can I do something to prevent them using so much CPU ?
Issue seems to be fixed in Xcode 9 Beta 6
I had this issue for a few hours and in the end I finally fixed it. IBCTT was eating up cpu and memory 5gb at one point and Xcode was unresponsive. I updated everything, cleared every cache and even tried throttling the tool but in the end the issue was simple but hard to detect. If that seems like your issue read on.
What you must do is clear all constraints on any view in the storyboard with errors if you are able to load it at least once. Then reset to suggested constraints and save.
If your storyboard has many views you want to Editor -> Refactor to storyboard the most complex or recently added/edited view.
You may notice in the crash report that it mentions an error not reporting a reason. Seems that I was having an error that I couldn't detect since the storyboard wouldn't load anyways. Refactoring out the view with the issue, then loading it first on a fresh restart showed the error and allowed me to clear constraints immediately.
Then restart Xcode by shutting down without force quitting to avoid the crash report and allow Xcode to start normally. Clear build folder then recompile.
This issue followed me through three installs of Xcode, 9.1 GM and 9.2 beta 1 and 2(9c34b) and a couple High Sierra beta updates (4 currently), so the issue seems to be deep within the AutoLayout engine. In all fairness to Apple constraints are a powerful idea but the variations involved on tools end is a nightmare.
Also my Interface Builder Cocoa Touch Tool is back to 84mb in Activity Monitor so I'm back to work....good luck!

Xcode 5 - out of control CPU and memory usage

I've been having issues lately with the latest version of Xcode 5. About a minute or so after launching CPU usage and Real Memory usage skyrocket. I've seen CPU usage as high as 400% and RAM usage as high as 13GB.
I'm on an i5 iMac with 16GB of RAM.
I've tried uninstalling Xcode and reinstalling, running all Mountain Lion upgrades, fixing recurring header loops, launching Xcode without indexing and a few other issues all to no avail. I'm now at a loss as to what I can do.
I would love suggestions of things to try. I've tried running my project on other i5 iMacs and I don't have this issue.
Thanks everyone.
I had this exact problem over the weekend with my Macbook Air and Xcode5. I tired resetting Xcode back to default, deleting the iOS simulator files, etc.
I've isolated it to it being the Source Control functionality in XCode. The high CPU usage doesn't seem to happen when the affected Project is not open, (Close everything and start a new Xcode project). I've disabled Source Control within XCode and and started using GitX instead, and CPU levels for XCode has dropped back to normal levels (5 - 15%).
I haven't dug deeper into XCode to see what could have triggered it.
I was running at 120% - beachball almost constantly - while idle.
What dropped me down to 1.3% was unchecking "Refresh local status automatically" in the "Source Control" tab in Xcode Preferences.
You can still have "Enable Source Control" and "Refresh Server Status Automatically" and "Add and remove files automatically"
I have actually figured out the cause of this memory issue in the source that I have, it was because one of the 3rd party library used was giving a lot of warnings and may be xcode is trying to do some processing around that. Just for test purpose, I removed the library and some of the classes which used that, and I was able to build the code faster. Now I plan to get to the bottom of the warnings and try to fix it. Not sure if all the people facing these issue is because of this but this was definitely the reason for my problem.
I've submitted a couple bug reports regarding this and while debugging it we came to a conclusion it seems to happen with upgraded projects. By simply removing all the classes from my project then reading them I no longer experience the horrible cpu usage and ram usage. This was primarily happening on 5.0 with my storyboards prior to simply removing them and re-adding them to the project. Xcode 5.0.1 also helped my performance.
*UPDATE
Since updating to Xcode 5.0.2 I no longer see these issues. I can finally work on large storyboards again.
Did you try to access many libraries at the same time or did you run a search trough out the system regarding a Xcode file or a project?This could sometimes bring the issue you have.running so many functions in xcode at the same time can bring these type of problems.if you can reinstall xcode after taking a backup of the data you need.
I just experienced similar issues with xcode after an update yesterday.
My memory on a 16GB macbook pro just dried out every time I opened xcode from 11-12gb of free ram to somewhere between 3-4gb with or without any projects open. I tried deleting the DerivedData folder to no avail.
The only solution that I have found that fixes the issue temporarily is for me to let xcode eat all the memory after starting and then doing a sudo purge in terminal.
After the purge I can work as normal with xcode with any projects using only as much ram as it needs to, but this needs to be done every time I start xcode.

Add large database file to iOS App bundle at compile time to avoid indexing?

I'm having a severe problem using the new versions of Xcode (4.4 & 4.5) in that, my project has a very large .sql database file stored in the project. This file cannot change, for many reasons... but it is +270Mb in size. This causes Xcode to hang on 'Indexing File...' and becomes completely slow and unresponsive to the point that I have to force quit the app, and cannot actually get any coding done. I have raised a bug report with Apple several times, but it is seemingly being ignored!
I do not want to disable Xcode indexing entirely as i find the code completion features incredibly useful.
My question is: Can i remove the database from the Xcode bundle resources, and then add it automatically at compile time?
Would appreciate any and all advice on how I could get round this problem.
Regards,
Sam
Incase anyone comes across this problem of Xcode indexing a huge unwanted file... I fixed it by setting the file type in Xcode to an 'MP3 Audio file'...
Doesn't seem to have any effect on the function of the .sql file once it's in the App, but stops Xcode trying to index it.
If anyone has a better solution for this, i'd love to hear it!

iOS crash only when NOT running via XCode. Concidence?

My app was crashing only when not running using XCode debugger. It was hard to track because I can't debug but I finally figured it out. It was because of calling release on some object not owned by me. Before I corrected it I searched and found 2 related questions here (links below)
iOS App Crashes when running by itself on device, does not crash when running through Xcode using debugger, or in simulator
iPhone crash only when device not connected to xcode, how to understand the crash log?
None of the above question has answered why no crash when running via debugger.So my question is why it happens ? I know reasons for debug/release specific crashes but this is crazy. Is it just by chance although it happened more than 10 times.
What you describe is not atypical of obscure memory-related bugs. You might also want to use debug-malloc at such times. Although that is not guaranteed to find everything. The reason (and it's been happening probably as long as there've been source-level debuggers) is that memory is laid out at least somewhat differently in debuggable code, and when running under the debugger. So the error results in a different piece of memory being (harmlessly) corrupted when under the debugger. When not under the debugger the location corrupted is actually something that your code cares about, and it crashes.
The same could happen in reverse, but you'd never know - if it crashes when run debuggable, you'd find it before switching to running outside the debugging environment.
Reiterating #jyoung's answer since I didn't see it the first time I glanced through:
Try running with Zombie Objects turned off.
In debug mode if you have it turned on it is handling memory allocation differently. Try running it without.
Go to Edit Scheme... > Run > Diagnostics. Then make sure zombie objects is turned off:
Then run through your code path again.
I had this same issue while working on a project modularised with Xcode Frameworks. Even after removing all the logic in AppDelegate and only returning true inside application:didFinishLaunchingWithOptions, I was still getting the crash. Then I switched to my project settings, in the Frameworks, Libraries, and Embedded Content section and changed the embed option for the frameworks I added to Embed & Sign. This was what fixed the issue for me. I hope someone finds this helpful.
I was having this problem as well and was fortunate to figure out the cause quickly, hopefully by posting here I can save someone else some wasted time. To clarify, my app would run with no issues when launched directly from XCode, but would crash immediately when launched manually on the iPad.
The app in question is written in Obj-C but relies on some 3rd party code written in Swift. The Swift code is included in the app as an embedded framework. I had to set "Embedded Content Contains Swift Code" to Yes in the Build Settings for the app (under Build Options), then the problem went away.
I experienced this symptom when I made a NSString, sent a UTF8String from it to another object, and assigned it to a char pointer. Well, it turns out that I forgot to retain the original NSString, which wouldn't have mattered anyway, since I also failed to realize that the UTF8String method (which is presumably an object that gives access to the pointer itself) operates in the autorelease pool. That is, retaining the NSString itself did not fix the problem.
I suppose this appeared to work just fine when attached under the debugger only because I had zombies enabled, so the pointer I had was still valid. I should see if this is the reason it worked; if so, this is a good reason to test with and without NSZombie enabled.
At any rate, this was probably poor design to begin with, and a pretty obvious newbie memory management mistake once I found it. Luckily the console in the Organizer window gave me some hints on where to start looking, and debugging ultimately showed me where my pointer's value was changing. Hope this helps anyone who finds the way here.
I had this issue when accessing SQLite databases from outside the [[NSBundle mainBundle] resourcePath] directory, which caused iCloud errors.
I discovered the error only by installing a Console app onto my iPhone which logged the errors.
Once I accessed the databases from the correct directory, the errors disappeared and the application booted correctly.

XCode 4.1 - Instruments Time Profiler

I'm trying to use Time Profiler, I've used it before.
I'm hiding system libraries, but all of my symbol names are HEX.
I'm running in debug, I have debugSymbols turned on....
I've restarted everything a few times and cleaned everything in between..
... anybody got any other ideas?
it's a bit of a pain because there are a number of variables that can cause this. some of the more common ones are:
sometimes you need to tell instruments where to find your files and/or symbols (Preferences->Search Paths).
have you enabled Link Time Optimization (LTO)? it should be off.
sometimes it helps if you do a clean/build.
sometimes it helps if you restart instruments.
in earlier versions of Xcode, it helped to use a central build directory.
verify that you are generating the proper level of debug symbols for all targets.
I no longer get this problem with the latest version.
Apple were no help in answering this for me - even though I used one of my Tech Support Requests. Must have had them stumped too.

Resources