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.
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
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.
I am trying to use the debugger that comes with JuliaPro 1.2.0-1. This collection of software provides an IDE (Atom) and a debugger ("Juno", or something).
A create a new .jl file containing only
function test()
a = 1
b = 2
end
And put a breakpoint on line 2, a=1.
I then either copy and paste it into the REPL (interactive julia pane), or select the code and hit Ctrl+Enter to do the same.
Now test() is defined in the REPL session. I then open the debugger. Now everything looks like below:
After a lot of trouble with poor documentation, I figured out how to start the debugging session by executing Juno.#enter test() in the REPL window. I do so, and it hits the breakpoint supposedly:
I then want to to interact with the variables inside test(). Such as calling print(a). It prints, but then some weird error occurs:
If I just type a, I get:
Supposedly c and fm are commands in the debug session, but they don't work.
So I'm completely confused. Is the debugger broken? Am I using it incorrectly? Thanks for your help.
Figured out the problem. JuliaPro simply doesn't have a working debugger. There is some conflict or outdated versions of the packages, causing the above problems.
I uninstalled JuliaPro, and instead installed julia, Atom text editor, and finally Juno through the text editor using this guide. Now print(a) and a both work as expected in the debug> session. However commands c and fm still don't work, and I'm not sure why (edit: see #pfitzseb comment).
Is it possible to set a starting point for the debugger so that every debugging session
will start immediately from that point (instead of starting from the beginning of the code)?
Or to express it differently:
Isn't it possible to somehow store everything until the breakpoint so that next time the debugger could just instantly resume to that specific breakpoint (instead of starting from the beginning of the code and pausing at the breakpoint)?. Is there any debugger that can do this?
I am using Microsoft Visual Studio Express 2012.
Thank you.
Use a Debugger in visual studio.
In your code, click on the line number, you will see a dot on the line.
When you run the program, it will 'pause' at the line you specify, you can then walk through your program line by line from there
You can use a breakpoint at a line that you want to inspect.
You have a description how to do it here.
You could attach a debugger to a running process, but i'm afraid that it will be on a random place of execution. You could make a wait for a key or button press in your code and attach to your program before continuing.
No. It would have to run the code up to the point you want to get all the variables etc in the right state. If you just set a breakpoint where you're interested from and hit F5 it should get there quickly enough.
If it doesn't get there quickly enough, jot down the variables used and make some unit tests round the troublesome functions instead. That will skip the 10 minutes.
I'm using Aptana Studio with Pydev 1.5.3 to debug my Django applications. I use PyDev's remote debugger and some code in manage.py and for most of the time this setup is working successfully- I can set breakpoints, inspect variables and step/continue through my code.
However, I'd like to execute arbitrary code at the breakpoint- the thing I really miss after switching from pdb to Eclipse debugging. There is an interactive console available in debug perspective but it is inactive for me.
So my question- is it possible to set up an interactive console in PyDev with remote debugger which could "inject" code at breakpoint?
strange, i am using pydev 1.5.6 for remote debugging and I can use the interactive console - i type the cmmand, hit enter, after a while get results back; check your firewall is not blocking anything (if you are sure, the interactive console works in local mode). there is even settings in pydev source code to set how much of stdout should be returned back to client (in chars), it should work
After some digging I discovered that I can use Expressions view to access variables properties and view results of class methods, but that still isn't a complete console at breakpoint though.
With PyDev 1.5.5 it should be possible:
In "Variables" view, you can right-click on a name, then select "change value".
The console is working as well, albeit a bit tricky.
It is only for inspection and in a very strange way: you have to input the text in the "Debug server" console, and you will get the output in the "filename" console.
Note also that you need to press enter twice, leaving an empty line.
While the "empty line" trick is documented, the issue about two different console for input and output is not, and I think it may be a bug.
On my development stack running Apache + mod_wsgi entering commands into the console had their output routed to the site's error logs. To resolve this you have set the stdoutToServer=True and sterrToServer=True to route capture all output to the PyDev remote debugger:
from pydevsrc import pydevd;pydevd.settrace('192.168.2.8', stdoutToServer=True, stderrToServer=True) #clone and put on python path: https://github.com/tenXer/PyDevSrc