I apologize in advance, this will be a very basic & general beginner's question:
Why is my debugger "breaking" on a line where I have not set a breakpoint?
Some more detail:
I'm working on a large buggy C++ project in XCode 12.4.
I've set a single breakpoint on function A. The debugger refuses to break on function A. Instead, it breaks consistently on function B. Function A and B exist on the same cpp file. I believe function B is supposed to be called AFTER function A, but they definitely do not call each other and are not called simultaneously.
I've definitely experienced the debugger stopping on various errors, but with a RED highlight, not a GREEN one - as I understand it the GREEN highlight only happens on a breakpoint I set myself.
Is this expected behavior? Am I missing something obvious?
(First post, please tell me if I'm doing anything wrong!)
EDIT: I solved & answered my own question below!
The most common cause of the debugger pausing at a place where you didn't set a breakpoint is the throwing of an exception. Some exceptions crash the program, which is where you get the red highlight in the debugger. Some exceptions don't crash the program. In those cases the debugger highlights the exception breakpoint in green.
If the debugger pauses your program with a green highlight, click the Continue Execution button (it's the second button from the left in the group of debugging buttons right below the source code editor) or choose Debug > Continue in Xcode to continue running the program.
These are all great responses and I learned a lot from them all - but it turns out the answer was much dumber.
For whatever reason, when I compiled, XCode did not delete the previously compiled binary. As for my breakpoint issue, I'm still not 100% sure what was happening, but it is solved now.
Here's how I noticed: Function A did not exist when I compiled it last time. I had created a String in function A. This string assignment returned a bad access error - so I assume it was assigned outside the program I was debugging!
Thank you to responders!
Related
I have been using Xcode recently a lot, however, every so often I'll inexplicably receive error messages about perfectly innocuous components of my code. I'd like to know how one diagnose these because as you can see in the buttom right of the screenshot, there's no log entry to go off of. Thanks.
Here's my screen shot:
It looks as if you have accidentally set a "breakpoint" in your code. You set a breakpoint by clicking on the left margin. A breakpoint stops your code automatically when it reaches that point.
Since you commented out the inside of the goBack() function, it stops at the first line of uncommented code.
The breakpoint you set is the little blue line to the left of the line self.scoreLabel.removeFromSuperview(). To get rid of it, click it and drag it into the main area of your code.
What's going on with this? I've never seen it before and have no idea how to turn this on or off. It doesn't do it with any other block of js code (or other code, for that matter). If I could get it to do this with every single block of code, that would be more than incredible...
If I am not wrong then most probably that's the code block where you have debug point/break point set to and so it's highlighting the same area. At least, that's what it does for C# editor; hopefully will be the same for Jquery as well.
To turn it off, remove the break point and see if it still remains.
I keep finding a scenario where my code stops on a breakpoint in Chrome's debugger, then when I use another tab like "Console", and go back to "Sources", I have lost the place where the code stopped, and I have to click singles-step to get "back on track", but this skips past the sought after breakpoint. Is there some way to get to where the debugger has stopped?
You can use the call stack portion to go to the current location the debugger is stopped at by clicking the top item in the call stack.
As the original writer couldn't submit an image due to his low reputation and the ongoing rules of the site, i will glady provide one for all of us!
You can click on the breakpoint in the list of breakpoints in the breakpoint panel in Sources and it will take you back there.
You can see a line number below. (eg:Line 152, Column 1).
So give Ctrl+G+line number. eg: Ctrl+G+152. You can see the breakpoint.
I have this application that I need to disassemble. I don't have a clue on how to stop the running code on the desired location, so I decided my best guess would be breaking upon a button click. But how do I capture button clicks? I know it has probably something to do with the Windows functions such as CallNextHookEx. I'm using IDA PRO to disassembly.
IDA PRO is used mostly as disassembler, for static analysis purposes. I'd suggest you to use Ollydbg (or some other debugger, if you want to) because it will suit better to debugging purposes.
I don't know if you can set a breakpoint on an API like that.
But you can do this:
Load the application in olly, or attach to it.
Generate the event by clicking on anything.
Stop the application from ollydbg(F12)
Use C(k)all stack(ALT+K)
You will see a few calls to functions, one of them is doing what you need. But you may need to go to upper calls to see the whole loop. So you will just try which one it is. There will be a loop in one of them.That loop will have conditional jumps and generate events, load forms, fill the app etc. And when you place a breakpoint on the right jump there, it will stop at each mouse click.
When I'm debugging apps, most of the times I find myself on a breakpoint like this, and I see from the beginning how the application is filling an empty form(it takes so long.)
I am trying to debug a very old C program in visual studio. I was stepping through some code line by line and came to a line DispatchMessage(&msg); I wanted to see where the code went next, so I clicked the "Step into" button, but I was not taken to any new code that processed the message, instead the little yellow arrow just stepped along to the next line down the same page...
Is this expected behaviour? How can I see what DispatchMessage actually did?
Could this be an indication that the window handler is not set up correctly?
extra info: The task I was tring to debug was the processing of a mouse click on a particular window. I had displayed the msg structure, and msg.hwnd was the window I had clicked on (I used Winspector to confirm). The msg.message was 513 (=WM_LBUTTONDOWN).
This is completely expected behaviour...
DispatchMessage() is implemented in User32.dll and as such, the source code is not available. For the most part, you have to treat Win32 API calls as blackboxes. At times, this can really make debugging Win32 code a challenge.
Remember, there are some tricks in your arsenal for debugging this kind of thing:
Go on treating DispatchMessage() as a black box. Place a breakpoint on the WndProc you expect to receive the WM_LBUTTONDOWN and continue debugging there.
Have Winspector log the messages coming into all of the windows involved. This can help make sure the message is received and in the order you are expecting.
If worst comes to worst, you may have to step into DispatchMessage() or some other API call, looking at its disassembly. Most of the time, nothing good comes from that (but I always learn something when I do).
Chances are that option #3 won't be necessary and your time would be better spent debugging around DispatchMessage() rather than within it.