Okay, I have just been through a massive amount of bull craparooonie with xcodes new LLDB debugger.
pretty much spent the better most of the day working on an error with my simulator that occurred after updating the debugger to LLDB.. so after figuring it all out I have rolled back to the GDB debugger by changing it in prefrences > edit scheme > debugger back to GDB.
This has solved my issues for now, however I have a question.
Apple are moving to a new set of LLVM suite of tools, I would like to know what I should do, is rolling back to GDB and waiting for a more stable version of LLDB to roll out a good idea? or can you think of something better?
pretty much my question is how best to handle the new upgrading of the xcode tools :)
The best solution is always to use what works the best for you. I also keep GDB active despite xcode complaints. LLDB gives bogus results often.
Related
I'm debugging an iPhone application and, well, gdb is just not doing it for me.
Are there any alternative debuggers or debugger uis I can use for XCode in general, or specifically for debugging iPhone applications?
lldb is the only supported alternative. Last time I checked it was in alpha state.
Life was better for Apple developers when we had a choice of IDE's (CodeWarrior, Think__, MPW, etc.) and debuggers (anybody remember Jasiks?), but anyways... consider this a business opportunity (to write a better debugger).
Not sure if you care to know this fact, since I have a feeling you're just not too thrilled with Xcode's built in debugging capabilities, but you CAN change the debugger between GDB and LLDB very easily. Look at the "To change the debugger..." section of Apple's Debugging & Analyzing Your Code document (right at the top, within the first screen of text).
I've imported an iPhone app that I have developed for iOS and am now maintaining it. I've came across a couple of bugs when trying to add to the iPhone's calendar, which I'm happy to try and sort out myself with a bit of debugging.
One problem is that when I go to run the application on the iPhone simulator, it seems to run an older version of the app than the one I am running. I've removed and added another button since then and the old button is still showing when I run it in the simulator. However, when I compile and run this on a device, it loads the correct version and displays the correct version number in the 'about' view.
But... my main problem is that it doesn't seem to debug on the device properly. The app actually works fine except for the calendar problems, but if I put a few breakpoints in so I can see exactly where this is going wrong, it just doesn't seem to step through! The app pauses, and Xcode says the app has paused! I can press step over and continue execution etc and it appears to work, but I can't see it stepping over the code, nor can I hover over variables to see their values.
I've tried reinstalling Xcode multiple times (I did have a problem installing an older version, so I had to wait until the next version was available before Xcode would install).
The stress is: Today is my last day at work, and I'd really like to get this app ready for iOS 5 before I leave.
Has anyone seen these symptoms before? Is there a debug setting that I've missed? Or is it a corrupted installation?
I wish I could help people a bit with more information, but I don't even know where to start looking here. Any code I can post? any settings? (not too familiar with this, I'm a .NET guy usually).
Thanks!
Sorry you're going through a tough moment there Connell; as you said you're not too familiar with all this, I'm laying down a few steps which might help you out. Some are pretty basic, yes, but I've resolved to these steps myself several times when I've encountered similar scenarios;
If you're testing on the simulator, do a 'Reset Content and Settings' from the 'iOS Simulator' main menu. This will remove all old data and settings and give you a clean start.
Do a 'Clean All Targets' from the Build menu. Then go to your physical project folder and delete the Build folder from it altogether before starting to build again.
Restart both XCode and the Simulator (and your Mac too if possible)
Make sure the mode is set to Debug and not Release or Distribution
Even on the device, remove the old app before putting the new one in, and restart it for good measure.
Delete all Provisioning Profiles from the device and install just the one you need.
On the code;
I've noted that the app appears to 'pause' like this a couple of times when I had accidentally created an infinite loop in the code. Double check to see whether there's something which may cause this.
Unless you haven't already done so, throw an NSLog or two in there to see if its really not being executed beyond the breakpoint.
I've had the exact same problem with a project that I started on xcode 3 and then switched to xcode 4. What fixed it for me was changing the compiler in the project settings.
The default compiler up to xcode 3 was gcc, while the default compiler on xcode 4 is LLVM gcc.
Now, I don't know exactly what's the issue that gdb could have with LLVM gcc, but switching the compiler back to gcc in my project settings and doing a clean build fixed my debugging issues.
Might be worth a try.
Have you checked which debugger is being used GDB or LLDB? Select Edit Scheme from the Product menu, and see what the Debugger setting is under the Debug scheme. You could try switching between GDB, LLDB, and None and running in between.
This is a really weird bug...
I'm working on an iPhone project using the camera feed and running it through an OpenGL shader to apply effects to it. However, every time I simply create a new GLfloat in the code, the debugger freezes when launched... I can't copy and paste the text because the whole of XCode freezes up, but I've cobbled it together from one of the log files:
GNU gdb 6.3.50-20050815 (Apple version gdb-1518) (Sat Feb 12 02:56:02 UTC 2011)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "--host=x86_64-apple-darwin --target=arm-apple-darwin".2#b2a16f854957b341^2#43"Xcode.IDEFoundation.ConsoleAdaptor.Debugger17"tty /dev/ttys000
(gdb)
The phone has not frozen, because I can hit the home button and carry on doing other stuff on it. However, Xcode 4 has completely frozen with a beachball running at 99% CPU, and I have to Force Quit and start it again.
However... The really strange thing is I have an iPhone 3GS, and when I borrow someone's iPhone 4 it compiles and runs fine. When I switch back to the iPhone 3GS, it's fine for the first time only... After that, it freezes constantly again.
Is this possibly something I am doing, or is it yet another XCode 4 bug? I wanted to try switching the debugger to LLDB, but that doesn't appear in my dropdown list in the Scheme window... Even though the Xcode User Guide states that both GDB and LLDB are available:
http://developer.apple.com/library/mac/#documentation/ToolsLanguages/Conceptual/Xcode4UserGuide/Debugging/Debugging.html
Thanks!
I am working on a video processing app as well, and this is exactly the symptoms i am having.
it works in waves.
I don't know what the reason for this is, but i am slowly gathering facts to solve it:
turning off GDB in Scheme settings removes the issue
with GDB ON, "wait for app to launch" seems to solve the issue (need more testing)
after getting into "stable freeze" mode, meaning, beachball on run every single time, Committing to repository removes the issue (??)
restoring device as a new device to latest iOS through iTunes solves the issue
all of the above except turning off GDB only solves the issue temporary - it comes back after few more runs...
Try to have terminal open, AND IN THE FOREGROUND (ON TOP OF XCODE) when the program builds and begins running.
Also, if possible, try downloading xcode 4.1. This seemed to fix this annoying problem for good, AND I can actually use the debugger again !
I had this problem once before and it started happening again all day today. I've tried everything from cleaning the project to restart both my iPad and MacBook Pro and even swapping a different cable.
What worked the two times this has happened:
I cleaned the project, changed the build target, and ran it on the iPhone simulator, iPad simulator. Then returned to the original (main) build target (the actual app) and ran that on the iPhone and iPad simulators. All of those ran correctly, so I finally ran the original app on the iPad device and it worked and has kept working.
Seems like a combination of cleaning the project, changing build targets, and running on the simulator is flushing something out that previously caused XCode and my iPad device to hang and freeze.
Good luck
In my case it was the wrong Code Signing Identity
Minimizing "NSLog" statements within loops helps for applications using OpenGL ES, OpenCV, etc.
I have a superweird problem:
I get a crash (EXC_BAD_ACCESS) when running my app with Release as active configuration on my 3.1.3 iPhone 3G. (works well in debug configuration or in simulator , works perfectly on device running iOS4).
My first guess was one setting in the Release configuration was erroneous/missing. In order to test it I just made a duplicate of my debug configuration and surprisingly I get the same error (although configuration is just a copy of the one working).
I don't understand why, with configurations that are supposed to be the same, one is working and not the other one.
If someone want to enlighten me, I am banging my head against the wall.
Thank you
NOTE: base SDK is 4.0 and deployment target is 3.0
Perhaps you have an unassigned local variable. Object-C follows how C does this. So in a release version you cannot assume that any local variable is initialised to 0 whilst in debug you can (in this case I would guess a pointer).
EDIT:
Pass -Wuninitialized to the compiler (or better -Wall) for the compiler to warn on these Apple gcc man page Note only works if optimizer is on.
You should check for memory leaks and handling of memory warnings. The amount of memory is probably the biggest difference between the environments you quote.
In another scenario I once found out that the simulator was faster, and therefore a certain race condition didn't show up, which did show up on the device. That's the second difference in the environments you quote: speed.
Try to pinpoint your crash and investigate from there. NSLog all didReceiveMemoryWarnings. Look for places where you made assumptions, i.e. about static information.
I fixed the problem.
It was three20 library fault. I had updated to the master branch that support iOS 4 but unfortunately this breaks support for 3.1.3. (thing that is not documented apparently)
Anyway I found this post that helped me to spot the problem. I just had to apply this patch and then I was able to run my project on 3.1.3 devices and iOS4 ones
Weird thing: why was it crashing when I was initializing a UIActionSheet (on a line of code not related at all with the Three20 lib)?
Thank you for your help.
I have an iPhone app that's been in development for about 2 weeks. We recently tried the "release" version of the build on a device, and to our great unhappiness, it crashes in one of the views with an "EXC_BAD_ACCESS".
This crash only occurs on devices, and only in the "release" build. Not only that, but it only happens the first time the app is launched! It is also 100% reproducible.
We have removed the small block of code that deals with data persistence, and have tried re-openning Xcode, cleaning the project, deleting and reinstalling the app, etc., as some other questions suggest.
Do you have any advice for a) what might be causing this problem, and b) how to go about debugging if it only happens in "release"?
Thanks
It turns out there was no problem in the code at all.
The reason it was crashing was that Xcode was trying to attach the debugger to the release build for some reason! We are still trying to figure out why, because we have checked the most obvious places, but I'm sure it won't be too hard to track down.
The build works fine if you install from iTunes or the Xcode organizer instead of building and running from Xcode directly, so it won't affect your end-users at all, as long as you are careful to check for other first-run issues.
We can only guess what the cause might but if it's 100% reproducible, then it should be a good candidate for some fprintf-style debugging.
Figure out the most probable place for the error to occur, and start putting "Got past xxx view initialization" style statements in to start narrowing the problem. It's tedious, but eventually, you'll get there.
In theory fprintf statements could affect the problem. However, it's rare that it does so, so it's a good place to start.