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.
Related
I'm debugging a program which works with multiple matrix and the breakpoints are not working. When I start the debugging, a pointer appears indicating where in the code the program stopped. The thing is, this pointer doesn't appear in a line with a breackpoint, it shows up in wherever it suits it and the worst thing is that enters a function which gives me the values of the coordinates in the matrix so you can imagine that I'm in a loop that is hard to get out.
I have tried using the "Step Return" to get out of that function but, as a loop, I always end there again. Also, the "Ignore breakpoints" is not activated.
Have I some debugging option activaded by mistake? thank you for your time
I didn't check the "Breakpoints" window in the "Debugging" prespective thus not seeing that there were some kind of breakpoints that I didn't know about and I don't have any idea appeared. I removed them and I could debug as usual.
I have 4 breakpoints but only 2 are getting hit. What I notice is that the breakpoints getting get hit show a small check mark in the breakpoints view.
What does this check mark mean and how can I activate my other breakpoints?
There is some explanation of the various symbols here:
What different breakpoint icons mean in Eclipse?
I've just tried it myself and it appears that your breakpoints are not disabled, but the little check mark only appears once you're actually executing the function that the breakpoint is in. So the reason your breakpoints aren't hit, is because there is no code path that leads into the code you're trying to debug, i.e. you're not calling it.
Found it. This is an issue where breakpoints other than on the main thread are not hit. This is an exclusive problem on the Samsung Galaxy S5 under Lollipop.
http://developer.samsung.com/forum/thread/android-studio-does-not-stop-on-some-breakpoints-when-connected-to-samsung-galaxy-s5-with-lollipop-5/202/277622?boardName=General&listLines=15&startId=zzzzz~
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 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.
In Xcode, say you write an app for the iphone and it has a runtime
error in it. What I've been seeing is that it just closes out the
program in the simulator but doesn't really hilight or give me any
feedback as to what line caused the crash... am I missing something??
Note: I don't consider the console to be very effective since
it just spits out an error, but I still need to find where in
the heck that bug is stemming from in the code.
In the console, above the stack trace, it should say something like "[ClassName selectorName] unrecognized selector sent to instance".
Make sure you really meant to send that selector to that class. If you post what it is, we might be able to help more.
To access GDB, enable breakpoints, add one to your code by clicking in the line number gutter, press build and debug and finally open the debugger (CMD+Shift+Y).
Look in the console (command-shift-R).
You can set a global breakpoint on exceptions, which will let you trace the exact point at which they occurred. To do so, select the Run | Show | Breakpoints menu item in Xcode to bring up the breakpoints dialog. Select Global Breakpoints (so that this will be enabled for all of your projects) and create a breakpoint on objc_exception_throw in libobjc.A.dylib.
Now if you start your application by choosing Run | Debug - Breakpoints On, or manually enable breakpoints in the debugger window (Run | Debugger) before running, the application should halt at the point where the exception is thrown. You can then look at the stack trace in the debugger window, where it will highlight the particular line that caused the exception.