I am using Eclipse 3.4 and debugging Java. I have set a couple of breakpoints and that works fine. I run to a line and then it stops. I can inspect and all.
BUT If you I choose to enter a class or more I loose where the breakpoint actually was, that is where the debugger has stopped. I have to keep track of it myself and scroll back and stuff.
I just want to go back to where the last breakpoint was ( that is where the debugger has stopped )
How can I do that?
Thanks!
=== EDIT ===
I know that I can watch the call stack but nothing there is highlighted so it is a bit difficult.
I do not know of such a possibility.
However, depending on the number of active breakpoints you are using, maybe the "Breakpoints" view can help. Here you can see all breakpoints you have defined. If you make a doubleclick on an entry, Eclipse jumps to the corresponding source location.
I just discovered (thanks to another very helpful post) that I can use GDB commands to create breakpoints that log information to the GDB console, whether debugging on the device or simulator. This is like NSLog, but much nicer in that you don't have to wait for the console to catch up, you don't have annoying timestamps, and you can turn them on/off at run time via the XCode breakpoint view).
Very nice, and I invested time figuring out how best to log messages and variables together. (Use the GDB command po [NSString stringWithFormat: #"Your message: %d %#",variable,[[object expression] description]]) for maximum versatility.
Everything worked wonderfully in the simulator. When I finally got around to device debugging, I was getting the messages just fine, but GDB was STOPPING on every breakpoint despite the fact that I configured them to auto-continue by checking the box in the breakpoint view.
I tried adding a "continue" commmand to each breakpoint, and it worked but GDB also started spewing information about every breakpoint hit and telling me "Continuing" after every line.
My questions:
Does this happen for you?
Can I change something so that auto-continue also works on the device
Can I tell GDB to be less verbose and only give me the output I print?
Please help!!
David
I've run into the same behavior. It turned out that XCode had duplicated the breakpoint at the intended line. Perhaps there's a bug where a left click occasionally adds a hidden breakpoint rather than disabling?
The solution was this:
Select the "Breakpoint Navigator" tab of the Navigator frame on the left
Look for duplicate breakpoints either manually or by entering the class name in the search box at the bottom of the Navigator. (remember that multiple project sections of the list may both contain a breakpoint for the same class)
Right-click on one and select Edit to figure out if it's the continue or not.
Right-click on the unwanted breakpoint and delete
David,
There are some useful console commands that you might want to familiarize yourself with.
info b (lists all breakpoints)
ena (enables all breakpoints)
dis (disables all breakpoints)
ena X (enable breakpoint number X)
dis X (disable breakpoint number X)
GDB also supports conditional breakpoints:
cond X [condition]
And, commands to execute automatically when a breakpoint is hit:
command X
Aaron
Another very useful option is a watchpoint - break only when given expression changes.
I'm using eclipse (and also the groovy-eclipse plugin), and sometimes I can't set breakpoints on lines. I'll double click the gutter, and the breakpoint will flash on then off, and it will set the breakpoint somewhere else, lower in the code.
I'll be able to set breakpoints fine for certain parts of the code, but some sections of the code will exhibit the above described behavior.
When this happens I have to restart eclipse, or cut the code i want to set the breakpoint on, and paste it lower in the file.
Anyone else experience this, or have an idea what causes it?
What version of Groovy-Eclipse are you using? We have recently fixed a few problems in this area. I'd recommend updating to the latest release, 2.1.1.
There is one known open issue in this area, documented here:
http://jira.codehaus.org/browse/GRECLIPSE-888
There may be more issues and if you find any strange breakpoint setting behavior after updating, then please raise a new jira issue for it.
Well, there are few types of breakpoints available in Eclipse:
Line Breakpoint -> Lines those will be executing. You will always get a breakpoint.
Method Breakpoint -> for methods
WatchPoint -> for member declarations.
BreakPoint -> for class level breakpoint
When u double click for breakpoint at a line containing bracket "{" or "}", the LineBreakPoint is set to the next executable line automatically.
I am trying to debug a small prototype for an iPhone App (iOS Simulator 4.1), compiled as Debug, with all the configuration apparently ok.
The application makes use of Cocos2d graphic engine and GDataXMLNode library (for XML reading). There isn’t much stuff going on. But on certain method, if I set a breakpoint, gdb simply “stops”.
Here’s the status line of the debugger after it hits he breakpoint:
And here’s the code that has the breakpoint(sshot):
note: the breakpoint could be anywhere in that function and it’s the same.
And this is the calling code (from another object)
self.map = [SimulationLoader loadMap];
None of the Editor buttons work when a breakpoint is set inside the “loadMap" (step into, step out, next, continue execution, etc.). I can stop and/or restart the debugging and it works (but goes back to the beginning). The gdb prompt, will let me write, but nothing happens. I cannot view object values or anything debugging related. I cannot resume execution, it won’t do anything.
The strange thing is that, if I put a breakpoint before or after that line (the loadMap), it all works, and I can step out or in, debug it and do all I want to do.
What am I missing?
A couple of seconds after the “failing” breakpoint is hit (and it “hangs”) the stack window clears. I believe all this happens because the gdb has stopped, but the question is, why does it stop there? What are the restrictions for this?
I’m compiling with LLVM GCC 4.2 for what is worth (but could probably change to other if that’s the problem, haven’t tried that because I don’t know much about the differences).
Is there something (maybe in your Map class?) that requires timing? For instance, a double-tap that's being interrupted by the breakpoint's being triggered at that spot?
(i.e., no breakpoint => double-tap registered, Breakpoint => second tap comes after breakpoint hits, so only a single-tap is registered.)
I don't see anything like this in your code specifically, but that's the kind of thing that could show mysteriously different behavior between breakpoints on/off.
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.