Even when I start GDB with --nx to ensure no configuration file is messing something up somewhere, the TUI mode simply does not display breakpoints.
I enable TUI mode via the --tui CLI flag, and then set breakpoints using break <line number>.
According to documentation here, set breakpoints should simply always be visible next to the source code, as either a lower- or uppercase letter "B", followed by either a "+" or "-" to indicate whether or not the breakpoint is active. The source code, by the way, is displayed normally without issues. But try as I might, no matter how many breakpoints I set, they are never shown.
Execution does stop at breakpoints normally. So this isn't some horrible issue that completely breaks GDB, but it would be rather nice to be able to see which breakpoints I've set and what their state is, next to the code.
Related
So I am using Qt Creator with LLDB as debugger.
To debug stuff I add breakpoints and when the code hits the breakpoint it stops and I can see the back trace and all and that's useful. However, sometimes I don't want to stop and I am only interested in whether the breakpoint is hit, or I want to inspect a value there.
I usually do this with adding debugging messages but that generally takes a lot of time to recompile the project and rerun the scenario.
I'm wondering is there a better way to do this, using a debugger, preferably LLDB.
All the break set commands take a --auto-continue option (one-letter: -G) that will instruct lldb to continue after stopping for the breakpoint (and running any of its commands).
You can run lldb commands when a breakpoint is hit (e.g. to do a backtrace or print some locals) using the break command add command or by adding any number of -C options to the break set command. You can also add a Python implemented callback to the breakpoint as described here:
https://lldb.llvm.org/use/python-reference.html#running-a-python-script-when-a-breakpoint-gets-hit
if you need to do something fancier to gather your report when you hit the breakpoint.
If you want to edit currently active break point you can do the following:
breakpoint modify <break_point_id> -G true
I am a beginner C programmer. Currently, I have Visual Studio version 1.61 September 2021 installed
on my windows 64-bit system. I also installed MingW64 and set up the environment variables to compile and debug with the purpose of writing, debugging and running my c programs.
I have been able to write and run my programs without any issues. I did notice that whenever I wish to debug my program, the debug toolbar that hovers on top has the buttons disabled and no line is pointed by the "yellow arrow".
I modified the "launch.json" file where I set the following:
"stopAtEntry": true,
This set the yellow arrow to point at the beginning of the program instead of the breakpoint and the debug toolbar buttons were activated. Though whenever I step-over on to the next line of code, the yellow arrow disappears and the debug toolbar buttons are deactivated once again.
This happens often on lines where I assign values to variables.
I am a beginner and I find VS Code quite frustrating, I would appreciate your input and suggestions. Thanks
UPDATE: I solved it.
So it turns out that there is nothing wrong with my debugger and it was behaving as it should. I noticed that it would always fall into that behavior whenever the gcc compiler was to execute the line including scanf(). The registers and variables in the watchlist would suddenly become "unavailable" this is because the compiler was waiting for user input.
Since VS Code did not show the running program on PowerShell, I modified the "launch.json" certain configurations to the following:
"externalConsole": true,
This allows for Command Prompt to open up, display the running program and allows for user input.
Once the user input is received the debug toolbar buttons are activated again and I could continue debugging. The watchlist variable also become available to analysis.
"stopAtEntry": false,
I set this configuration to false because I did not wish for the debugger to begin at the beginning of the program.
This was certainly frustrating but after finding the solution to this "issue", I bet that my endorphin and oxytocin levels are off the charts.
Very thrilling, this is what I love the most about problem solving.
I am trying to debug a simple program with the help of the Rstudio debugger. I first ran the program without the debugger. I then set a breakpoint as I have shown below, and checked "Source on Save". Then I saved the file, and the control came and halted at the breakpoint. I hit F10, typed b in the console, and got the value of b. I hit F10 again, and typed c in the console expecting to see the value of c. But, instead, Rstudio exited the debugger mode. Can someone explain what is happening?
The c command while using interactive debugging has a special meaning. It is used to continue the normal execution of the function.
Similarly n is to execute the next line in the function, s is used to step into the function etc. So even these variables would behave differently if you use them as variables.
To get the contents of "c" variable you can use print(c) instead in the console.
When I am debugging in Microsoft Visual Studio 2017 my "Registers" window shows no data available. What can I do to fix this?
As Sneftel stated, you cannot inspect data in the debugger unless you break the execution of the process. During execution, things would be changing far too quickly for any data display to be meaningful.
You can use the "Pause" button in the toolbar to break execution, and then you will see everything in the debugger: the current source line, the contents of registers, your "watch" variables, the full contents of memory in the "Memory" window, etc.
You can also set a breakpoint on a particular line of code, and then execution will break once that point is reached.
Once paused, you can then single-step through your program's code. This means that one line of code (the very next one) will be executed, and then the program will break again so that you can see everything in the debugger. This is an excellent troubleshooting technique—one that you should be well-acquainted with. In fact, I recommend that you single-step through every line of code that you write, just to make sure that it works correctly. You can also modify the contents of registers and variables (or, really, any location in memory) while you are single-stepping, giving yourself a way to test potential bug fixes or even introduce bugs (e.g., invalid input) to see how your code handles them. The default keyboard shortcut for single-step is F11.
You'll find more information about using the debugger, and the available keyboard shortcuts, here on MSDN. As you can see, that article confirms my answer:
Most debugger features, such as viewing variable values in the Locals window or evaluating expressions in the Watch window, are available only while the debugger is paused (also called break mode). When the debugger is paused, your app state is suspended while functions, variables, and objects remain in memory. While in break mode, you can examine the elements' positions and states to look for violations or bugs.
(Edit-and-continue is not available in assembly projects. You will need to stop execution and rebuild if you want to make changes to your code.)
For those with the "No data available" message, you can right click in the Registers window and choose what you want to see (UC, MMX, SSE, etc). It seems like by default there's nothing selected in Visual Studio 2019. At least, on mine there was nothing selected.
I am scripting Illustrator CS5 with the Extendscript Toolkit.
I set several breakpoints in my code, they show up as red dots next to the line number. But when I run the script, it executes all the way to the end without stopping and the breakpoint dots turn dark.
What am I missing here?
Thanks!
Check to make sure $.level isn't set somewhere, either in your code or the app's startup script. If $.level is set to 0 or 1, breakpoints are disabled. You might also try explictly setting $.level=2 at the start of your code, to ensure breakpoints are turned on.
This is a common error in the ESTK (Extendscript Toolkit), I believe it's a bug - breakpoints should not get disabled by starting the script.
Most likely pressing F11 (step into) will also make the breakpoints turn into a darker red colour (disabled). But in this state (stepping through the code) you can enable the breakpoints again and they will get hit when you let the script run on (F5).
(Shortcuts are for the Windows version.)
Another thing to try is to first start the script from the scripts panel in InDesign (run it once), and then start it from the ESTK. If you use the targetengine directive to set a specific engine name, this might even be necessary.