I am running instruments to analyze memory leaks in my application,
but it does not show any responsible libraries for any allocations:
Neither it shows any methods/variables in stack trace, it just shows this:
Is there any setting that I am missing? It used to show earlier, it has stopped showing these just recently.
Here are a couple screen shots of how I currently have mine configured. Maybe these will help. First thing I would do is check to make sure that within the current scheme, you have your "Profile" Build Configuration set to Debug like in the first image below.
Also, have you tried right clicking on "Responsible Library" header to remove the checkmark and re-add it like in my last screenshot, to give it a virtual smack? I'll keep looking to see if I can find out anything else more helpful.
Close instruments. Make sure spotlight indexes your build artifacts. You can do this manually by running mdimport from the command line. Reopen instruments.
Obviously, make sure your derived data location, etc. is not in spotlight's blacklist. This is controlled by System Preferences.
Instruments relies on Spotlight for a lot of what it does.
Related
I'm not exactly sure how to debug this but it seems that I'm getting EXEC BAD ACCESS in the main function of my app. There's no trace or logs of what's going on. I have NSZombiesEnabled but it doesn't seem to be showing anything. How would I debug this?
The first step in debugging is to find out where the crash happens. To do this you need to be able to reproduce the bug.
The Xcode debugger will usually tell you where the crash happened. It doesn't happen in main(), that's simply the entry point for the app and the top of the call stack. You can zoom in to the call stack with the slider at the bottom of the Debugger pane (in Xcode 4).
If the stack trace doesn't include any of your own code, then you may need to set an exception breakpoint in the Breakpoints pane and try again.
If all else fails, you'll have to do some digging:
1) Find a reproducible case where you can make the app crash every time (or almost every time) using the same actions.
2) Since you know what you're doing to make the app crash, you roughly know where in the code you should look. Set breakpoints at strategic places (or use NSLog). After some fishing, you'll find the exact line where the app crashed.
3) Fix the problem. :-)
It may be helpful.
Mainly you are getting this error because you have released something which is useful in furthur.So try to focus on the release.comment the line where you have used the release
Have you tried too clean and rebuild your project, and restart XCode. Latest versions of Xcode sometimes does EXEC BAD ACCESS int the main function with no reasons…
Turns out, pushing multiple view controllers simultaneously will cause this. Hard to debug that!
I have a strange issue and possibly a bug. My NSLog statements have stopped working completely, they do not print even in view did load, application didfinishlaunching etc. The have all turned a brown colour (the same colour as a pragma mark in xcode) and they all have a warning saying 'expression result unused'. Has anyone ever seen this before or know what to do? Am i running in some kind of weird mode? Im running xcode 4.0.2.
Many thanks
Jules
for completeness, I had the same problem and the answer was different, hope it helps someone else who bumps into this post:
I had a framework (an Amazon one) redefining NSLog, went there (Cmd+Click on the Brown NSLog) and commented out the redefinition...
The actual problem was the release_build set to 1. So it wasn't recognizing nslog, as you said it was set for a release build.
I had the same issue :
what worked for me is given below:
Remove the derived data folder
After removing derived data perform the clean action (You can see this option in the product menu)
Quit the Xcode and start it again.
And this did the trick all my NSLog were working fine.
Hoep this helps
Ensure that scheme chosen corresponds to Debug mode because sometimes the pch file might have some definitions such that logging is done only in the debug mode
(Scheme is on to the left of the place where you select iPhone Simulator / iOS Device)
In the view select Debug Area
(There are 3 view buttons, on the top right hand corner of Xcode, press the center button)
Select "Show variables view and the console"
(In the debug area (bottom) there are ther 3 buttons, press the center button)
I had the same issue and the problem was that I was building an Ad Hoc version (schema was for Ad Hoc build). The warnings disappeared when I built for debug.
Try changing the dropdown menu at the bottom of the console to 'All Output'.
if you are using libraries like 'KScan' or 'iKEA' or 'kdc-scan', so it can happens that, they will call methods like this one 'redirectNSLogToDocuments'.
in my case the object of 'iKEA' call the method 'CheckIfDeviceConnected' and this one redirect all nslog outputs to documents. after commenting out, all nslogs works again :)
hope this will be useful for some one.
some steps :-
1) "Clean all targets" or delete your build and rebuild again.
2) If step 1 doesnt work , reinstall xcode
I am working on an iPhone project containing a ton of code. The application receives outside requests and performs actions. However, I cannot figure out exactly where the app begins executing code for a particular event. Is there some functionality in Xcode which would allow me to solve this problem?
Thank you.
Have you tried setting break points in your code? Click on the line numbers column in Xcode on the number to set a break point.
Without knowing more about what these requests are or where they are coming from, its hard to give any advice on what tools Xcode might have, but looking in any project files named <xxx>AppDelegate.m or <xxx>Controller.m would be a good start, placing breakpoints on likely sounding methods.
I figured out that you can use the Instruments Profiler to this end.
Start the profiler
Choose "Time Profiler"
In the bottom left section make sure the following are checked: Show Obj-C only and Hide System Libraries
In the timeline, click on the the point before the event occurred.
Click the left-most icon in "inspection range" (located on the top-bar immediately to the left of clock)
In the timeline, click on the point after the event completed. (optional)
Click the right-most icon in "inspection range"
Inspect the Call Tree.
I'm still relatively new to XCode. I'm trying to build an iPhone application and after my application didFinishLaunchingWithOptions method runs but not inside of any code I can find I get this error:
[58036:207] *** -[_PFArray release]: message sent to deallocated instance 0x17cd2fe0
I have no idea what that means apart from the fact that some array somewhere is being released when it's already released?
The real problem, is that I have no clue how to use the information provided there to find where the error is. There is no line of code to look in, no variable name, etc.
How do I use this information to find what I'm looking for?
try enabling zombies, then xcode puts a breakpoint automatically to the line where this error occurs. Google nszombieenabled for more information
Edit: Well, I don't have much thing to do so here your guide,
Open instruments. It is an application and you can find it in "~/Developer/applications/instruments" (in a default installation path). Instruments will be your right hand so master it well.
In the opening screen, you will see a bunch of templates. Open the one named "Zombies". Note: You will often use the template named "Leaks". It shows all the memory leaks you forget to release.
From "choose target" (top left corner), select "choose target", and again select "choose target". From here, browse the project directory, and choose "build/Debug-iphonesimulator/executableName". Here I assume that you have built your project in debug profile with nszombieenabled to true. If not, build it so and reply 3.
Press record button (top left corner). The simulator will appear and your app will start. Then reproduce the error you have encountered.
Instruments will interrupt the app showing a message bubble. Do not close the bubble. From the bar in the middle of the window, select "objects list" instead of "statistics". Now, all the objects allocated up to this point lies in a list sorted by their memory addresses. Here scroll down to the memory address written inside the bubble. You can type the initial letters for fast scroll. Then double click the line you found. This brings you to the code where the object is allocated IF THE CODE IS YOURS. If it is not, then ios allocated the object. But do not worry, and double click the lines below and above to see if they are allocated by you. This should give you a hint where may be the problem is since these lines triggered ios to allocate the object (possibly).
This is all I can say. I hope you can find what causes this error.
I'm programming an application in Objective-C and I'm getting this error:
MyApp(2121,0xb0185000) malloc: *** error for object 0x1068310: double free
*** set a breakpoint in malloc_error_break to debug
It is happening when I release an NSAutoreleasePool and I can't figure out what object I'm releasing twice.
How do I set his breakpoint?
Is there a way to know what is this "object 0x1068310"?
When an object is "double-freed", the most common cause is that you're (unnecessarily) releasing an autoreleased object, and it is later autoreleased when the containing autorelease pool is emptied.
I've found that the best way to track down the extra release is to use the NSZombieEnabled environment variable for the affected executable in Xcode. For a quick rundown of how to use it, check out this CocoaDev wiki page. (In addition to this page, Apple has documented some incredibly obscure yet useful tips for debugging code in Xcode, some of which have saved my bacon more than a few times. I suggest checking out this Technical Note on developer.apple.com — link jumps to the section on Cocoa's Foundation framework).
Edit: You can often track the offending object down within the Xcode debugger, but it's often much easier if you use Instruments to assist you. From Xcode, choose Run → Start With Performance Tool → Object Allocations and you should be able to trace the offending object back to where it was created. (This will work best if you're enabled zombies as discussed above.) Note: Snow Leopard adds a Zombies tool to Instruments, accessible from the Run menu as well. Might be worth the $29 alone! ;-)
There is also a related SO question here.
You'll find out what the object is when you break in the debugger. Just look up the call stack and you will find where you free it. That will tell you which object it is.
The easiest way to set the breakpoint is to:
Go to Run -> Show -> Breakpoints (ALT-Command-B)
Scroll to the bottom of the list and add the symbol malloc_error_break
I just want to add my experience in addition to the answer of Quinn Taylor.
In one of my apps, I have to parse and save data into core data objects and later on get these objects to display on the views. In fact, the app works just fine and does not crash at all, until I tried to do a stress test of navigating back and forth multiple times, tried to open multiple views as fast as possible. The app crashes with the above message.
I have tried all the methods that Quinn suggested in his answer and still failed to find out where was the exact cause.
I set NSZombieEnabled=YES, and NSStackLogging=YES, ran the command shell malloc_history to find out why, but still no luck. It always points out to where I save the data into core data objects, in fact, I have checked thousand times the over released objects there, nothing odd.
Running in Instruments with various tools(Allocations, Leaks, etc...) still did not help. Enable the Guard Malloc still got nothing.
Final rescue: I tried to come back to the views where the objects were taken from Core Data and sent a retain message to all of these objects, and took note to these changes. It solved the issue!!!
So, I found out that I failed to retain one, that's exactly the cause. Just want to share my experience so you have another rescue for your app.
Open up the debugger console by pressing Cmd+Shift+R. There, type
break malloc_error_break
to set a breakpoint at the beginning of the malloc_error_break function.
If you want to find out what object is located at address 0x1068310, you can type the following into the debugger console:
print-object 0x1068310
Of course, you have to do this while the object is still alive -- if the object has already been freed by the time you do this, then this will not work.
Please find the below steps for how to find the object which is free and crash the application.
1) Click on the "Breakpoint navigator". 2) Then click on the
"+" button which is below. 3) Add the "Symbolic
Breakpoint..." from the list. 4) Add the
"malloc_error_break" keyword on the "Symbol" option.
Or you can also refer the below GIF presentation.
For me the issue was solved by
(gdb) call (void)_CFAutoreleasePoolPrintPools()
right after the crash. The address at the top of the stack was the address of the culprit. Threw in a retain and voila.
The address given in the log message did not get me anywhere. It never showed up in any of the various Instrumets. Apparently a pointer to some internal data which had already been freed.
Adding a symbolic breakpoint in Xcode 4
Just an update to make this relevant to Xcode 4...
From the Xcode 4 User Guide:
To add a symbolic breakpoint . . .
In the bottom-left corner of the breakpoint navigator, click the Add
button.
Choose Add Symbolic Breakpoint.
Enter the symbol name in the
Symbol field.
Click Done.
This is what the malloc_error_break breakpoint looks like in the Breakpoints window in Xcode.
Need to check the boxes to make it work.
alt text http://www.martijnthe.nl/wp-content/uploads/2009/08/Afbeelding-1.png
Check your classes and look under the dealloc method. Make sure you care calling [super dealloc].
I had this exact same problem and found out I was calling [self dealloc] instead. Just not paying attention.
In Xcode, click left of the line number to set a breakpoint. Then you can launch it by doing a "Build and Debug".
It is recommended to not have object that you create be autorelease since memory is a commodity on the iPhone. Apple recommends explicitly calling release.
To find these kinds of memory and pointer problems in general, you want to run your code against a runtime memory error checker like Valgrind. This should be able to point out lots of things your code is doing wrong, beyond those that cause it to crash.
Valgrind can work on OSX (though it says it's "unsupported and incomplete and buggy"), and with a little hacking someone got it to work on iPhone SDK executables.
Even better you can try Instruments, which is part of XCode. There's a tutorial for running it here.
If malloc_error_break is not helping...
The best way to solve this error is to run instruments with the NSZombies turned on. Instruments will flag you when the Zombie is messaged and you can trace directly back to the line of code.
Snow Leopard required, what a lifesaver though!
This is usually caused by some inspector, such as safari or safari preview. Refer to post or post and question.
Remove the select of AutoMatically Show Web ...., will remove this issue.
Note, just close safari or safari preview will not remove this issue. And you have to deselect both of safari and safari preview.
If this will not do, refer to this answer or post to debug it.