I set a breakpoint immediately following these lines:
NSInteger index = [self.aCombobox indexOfSelectedItem];
NSString *nameSelected = [self.names objectAtIndex:index];
If I then roll the mouse over nameSelected, it shows a value of “nil.” And if I type “po nameSelected” in the debugger console, it says the string “does not appear to point to a valid object.”
So I added an NSLog to print nameSelected, which duly printed the string. And, once debugger is below the NSLog line, if I roll the mouse over nameSelected, it shows the correct value.
Is there some reason why the debugger behaves this way? It makes it harder to identify where the real problem is.
Me (and millions of other iOS developers) do this all the time and have no issues. Though it seems a stupid query, have you made modifications to the source while debugging (specifically, added lines of code)? If so, the debugger is still pointing to line X from the .o file while your source is out of sync.
The real answer is Tommy's comment to this old question of mine. It was a Xcode newby mistake. Sorry to have left this hang out there so long,
Actually, our experience is that the iOS enabled GDB is buggy as anything. We've observed these kinds of bugs quite often.
There might be a solution, but most of the time we just sucked it up and resorted to NSLog Debugging.
Related
I'm not sure if this is possible. Here is an example situation:
Something is printing to my console and I don't know where it is coming from in the code. I did a quick search using the Finder in Xcode on terms such as 'NSLog' and 'print'. Nothing relevant came up.
Is there any quick way that Xcode has of finding where the source of the output is coming from ?
Kind of like when you right click on a method and you have all the options of exploring different parts of the code associated with that method.
Also: are there other functions that print besides NSLog and print?
Thanks so much!
Try running in the debugger, with breakpoints set on printf, NSLog, etc. When you hit a breakpoint do a backtrace (bt) to see where it's being called from
There's a plugin LinkedLog for that. You replace all NSLogs with LLogs and then will be able to just tap on link in Xcode's console to get to the line caused it to appear.
Didn't try it myself, but definitely will.
I'm getting an EXC_BAD_ACCESS crash at startup and Xcode says the crash is at the NSApplicationMain line in my main.m file. The crash happens 99% of the time and when I run it with zombies enabled the crash never happens. Has anyone seen this before? How can I possibly debug this?
If you are running Xcode4 there default is to show very little of the call stack, move the slider at the bottom to the right. You may well not find any of your code but you should be able to get a good idea of what was going on. If it was a notification or selector after delay you will see that the Runloop dispatch and that will also give you a clue.
Finally, go old school, the way we did it in the day of coding forums, punch cards and only a couple of compiles a day: study your code. Know what every line of code does and why it is there.
As #Danra said, do run the Xcode Analyzer and fix all complaints.
The reason why running with zombies enabled resolves the bad access is probably that a) In this mode objects don't really get deallocated when their retain count reaches zero, and b) That your original crash is due to accessing an already deallocated object.
However with zombies enabled, instead of the crash I think you should see in the debug console the access to the deallocated object.
I also recommend using the static analyzer ("Analyze" in the XCode menus) in hope that it finds the culprit.
I am relatively new to Xcode4 and I would like to know how can I identify a double release with it.
In the debugger I see a line like *** -[NSConcreteMutableData release]: message sent to deallocated instance 0x60b63fe0.
The problem is that knowing the address doesn't help a lot identifying the object and also the object type doesn't help too much identifying it.
I read http://www.friday.com/bbum/2010/01/10/using-malloc-to-debug-memory-misuse-in-cocoa/ but I did not found this to be too successful.
You can enable the NSZombieEnabled environment variable - see How do I set up NSZombieEnabled in Xcode 4? for instructions on how to do this on Xcode 4.
What this means is that released objects are kept around in memory, so the debugger can still find out the type of objects. When the crash occurs, you are told of the object in question.
The "Zombies" Instruments tool is great for detecting bugs of this type - it actually enables NZZombieEnabled and you can use it to find out exactly which line of code the crash occurs.
You can replace the release method using categories for testing purposes, this is not designed to work like that as part of the language but in the past I have found success it trying to do some testing, usually all you find out is that an autorelease pool is releasing you object.
You are sending a release message to something which already is released or having retainCount 0. Hence, its giving such an error message. Actually, my answer over here might help.
Use the profiler for Zombies to track down the actual object. It will automatically enable NSZombies and more importantly keep a history of all release and autorelease messages.
Use Profile menu command under Product.
In the profiling template selection dialog that appears, select Zombies.
Click the Record button in the toolbar (Command-R) to begin recording. Use your app normally. If a call is made to a deallocated object, a flag is inserted in the timeline pane and a Zombie Messaged dialog appears.
Click the focus arrow next to the zombie’s memory address to display the memory history of the zombie object in the detail pane, along with corresponding reference counts and method calls.
Here is the apple documentation with pictures:
https://developer.apple.com/library/content/documentation/DeveloperTools/Conceptual/InstrumentsUserGuide/EradicatingZombies.html
Try using the property retainCount. If an object has a retainCount == 0 then it will be freed. Ultimately you will not be able to send it a release message.
I'm trying to get better at using the debugger rather than just always printing my debugging message out via NSLog. This morning I thought I had a great use for it - to find how the changed values of a KVO dictionary. But when I set a breakpoint just after the appropriate code and ran with debugging on, all I saw in the debugger was this in the summary:
{(int)[$VAR count]} key/value pairs
and expanding the item never gets to any key or value.
But when I print out the "change" dictionary via NSLog I get the key and the value:
[timestamp] appName[3643:707] observeValueForKeyPath new filePath change: {
kind = 1;
new = foo;
I guess I have two questions:
Is there a way to get dictionary keys and values with the Xcode debugger?
Is there a set of rules of thumb for using the debugger vs printing log messages?
I'm (still) using Xcode 3.2.6.
Thanks!
EDIT: I realize that "foo" is not a valid file path. At this point I'm still testing sending a value around via KVO.
Set a breakpoint on the spot you want to check the value of the variable and run your application. When the breakpoint gets tripped put your mouse over the variable in the debugger. A little popup should come up, move your mouse over the arrows on the left side and another menu should popup. Click on "Print Description" and it should display something similar to a log in the console.
It is just a case by case method but a lot of it is just personal preference. You will just have to find what works for you.
If I am going to check a variable a lot at a one specific point, I will go with a log. It is usually the quickest way to see if something is working right
If I am checking how a part of the code affects a variable I will use the debugger and step through the code. It is also useful for checking the values of lots of variables in a section of code.
You can using a future set, which defenetely working in Xcode4
When u setup breakpoint, where is a option to don't stop execution of program and write to log anything what u want.
I'm not sure if it working well in Xcode 3 bcs I familiar with 4 but here is work.
so i have a program i am developing and as im fairly new to objective-c and cocoa touch im not very familiar with the concepts of memory management in ipad app development. my problem is that my program keeps crashing without any warning and without telling me why, i turned on breakpoints and it shows an exc_bad_access signal. which leads me to believe that im not handling the memory properly. or its something else that i've over looked in my efforts. either way i need some help. if anyone can take a look at the app and tell me anything that may be causing it to act the way it is that would be great.
the point of the program is that it shows 20 mayan glyphs of the numbers 0-19, you drag the glyphs one at a time into the white 'drop zones' and it adds them and displays the result. however almost every time as soon as the second glyph is dropped in it quits, or it will display the answer and when you remove one of the glyphs to add another set it will quit then.
any help would be greatly appreciated. thanks stackoverflow :)
source files here
why don't you read Apple's documentation, which is reasonably excellent on this particular topic?
http://developer.apple.com/iphone/library/documentation/cocoa/conceptual/memorymgmt/memorymgmt.html
Get to know the debugger. At the point at which you see the EXC_BAD_ACCESS and the program halts, look at the call stack to actually see what the source of the signal was.
Also, in the case of an issue with accessing an object that has already been deallocated, it's useful to have NSZombieEnabled set to YES in your environment variables. To do that open the info panel for your executable (Groups & Files pane, expand 'Executables', and open the info panel for the executable your project builds) and in the "Arguments" add an environment variable named NSZombieEnabled with the value YES. With this enabled any objects which are deallocated are actually turned into an instance of a 'zombie' class which will allow you to catch any messages sent to those instances.