I have created a custom toolchain and launch configuration to allow debugging on a remote target.
I've got the debugging working so that I can step through each statement. However, the stepping doesn't always match up with the position in the code editor.
For example, when debugging this code:
int x;
for(x = 0; x < 10; x++)
{
printf("%d\n", x);
}
The cursor will stay on the first line of the "for" statement rather than jumping onto the "printf" statement when stepping.
However, when I turn on "Instruction Stepping Mode" it does end up stepping onto the "printf" statement.
Any ideas would be very much appreciated. Please let me know if I can provide anymore details.
Best regards,
Alan
Just to draw a line under this one, it was due to me having compiler optimizations turned on... turn them off and it works fine.
Alan
Related
I am new to both Julia and Visual Studio.
whenever I try to subtract two numbers
i.e. 3 - 5 I get 10
I am however able to add a negative number
3 + - 5 gives -2 as expected
The behavior also occurs with the .- and .+ operators. I thought there might be something wrong with my "-" character so I tried copying and pasting from the julia page on mathematical operators (https://docs.julialang.org/en/v1/manual/mathematical-operations/) to no avail.
I was unable to find any one else with the same problem. The problem appears to be limited to Visual studio as subtraction still works fine when I run Julia in terminal.
I am using Visual Studio Code 1.71.2 with the julialang 1.7.12 extension and Julia 1.8.1
EDIT-1:
If I copy and paste the code from Visual Studio Code into the julia terminal (not terminal in VSC) it works. However, if I run the code using julia the-script.jl in the terminal I still get 10 for any subtractions performed. I have also tested editing the script with nano and then running it and I am encountering the same problem.
EDIT3: As was pointed out by several responders the issue was not with VS code
Thank you for your help
Could someone explain where my code is breaking the function -?
I am unable to reliably break it so that I get 10 whenever I try and subtract, but I have been able to reproduce the error with the above script
# #make the neutral model that I have in R in julia and benchmark both models
# #imports
using Random
# #set the seed
Random.seed!(125)
#set the initial arguments
num_sp_local = 10::Int64;
init_sp_abundance = 100::Int64;
mig_prob = 0.01::Float64;
#meta community is uniform
num_sp-meta = 10; #ERROR IS HERE - function redefined to be 10
#the number of time steps to run the sim for
time_steps = 100000;
for i = 1:50
println(i - 35)
end
The error can be seen above num_sp-meta = 10; redefines the - function to be 10 irrespective of what is being subtracted.
This has nothing to do with VS Code, changing your editor/IDE is a pointless waste of time.
As #JoachimSauer suggested, someone (maybe you?) has re-defined the - function in your Julia instance.
Try fixing - by resetting it to Base.- like this: -(x::Int, y::Int) = Base.:-(x, y)
That might not work, depending on how the change was originally done.
Restart the REPL in VS Code. Perhaps the redefinition happened inside the script. Try to run 2 - 3, without running the-script first. This should work now.
This means that the change happened inside the-script.jl. Look for redefinitions of - inside that file.
If the above still doesn't work, the problem lies in some other library or script which is run. If so, try starting Julia like this:
julia --startup-file=no
and then run 2 - 3 or something like that.
I use dbstop error a lot when working in Matlab. A good portion of the time, a mistake causes errors to be thrown inside of built-in [m-file] functions, which then causes Matlab to stop execution and open the file. However, it's almost never helpful to debug inside of the built-in file, so this ends up disrupting my workflow. Might there be a way to set things up so that Matlab backs out of the built-in file in the debugger (never opening it), leaving me at the function call?
Although I've never found a way to tackle this problem properly, it's fairly easy to hack together a workaround:
Create a script containing something along these lines:
S = dbstack();
file_paths = cellfun(#which, {S.file}, 'UniformOutput', false);
builtins = ~cellfun('isempty', strfind(file_paths, matlabroot()));
stack_depth = find(~builtins, 1, 'first');
for ii = 1:stack_depth-1
dbup(); end
Save it somewhere that makes sense to you, and place a shortcut to it in the MATLAB toolbar.
Then, whenever this problem occurs, you just click on your little shortcut, which will automatically take you to the first non-builtin function in the debug stack.
Based on Rody's answer and feedback from Mathworks, this is the closest you can get at this point (R2016b):
S = dbstack('-completenames');
builtins = ~cellfun('isempty', strfind({S(:).file}, matlabroot()));
stack_depth = find(~builtins, 1, 'first');
hDocument = matlab.desktop.editor.findOpenDocument(S(1).file);
matlab.desktop.editor.openAndGoToLine(S(stack_depth).file,S(stack_depth).line);
hDocument.close();
if stack_depth == 2
dbup();
end
This shortcut will:
Open up the closest user function to the correct line.
Close the builtin function that opened when the error was thrown.
If the error happened only one level away from a user function, switch to that workspace.
The problem is that dbup() only works once - after the call, execution in the script stops. There's no function to switch to an arbitrary place in the stack.
I need your help. I want debug a matlab code after specific iteration.
Suppose the following is the code:
**im=imread('C:\lena.tif');
[m n]=size(im);
for i=1:2:m-1
for j=1:2:n-1
enter into a function
..................
..................**
Suppose, when i = 505 and j = 460, the program will enter into the Debug Mode, and then I will debug the rest of the code using STEP IN (F11)
Please help me. Please please please......
Many thanks in advance.
Regards
- Jessy
As others have stated in the comments, you can use conditional breakpoints. It is important to point out that this can be done both interactively through the MATLAB editor or programmatically
dbstop in FUNCTION_NAME at LINE_NUMBER if CONDITION
Furthermore, you can also combine conditionals within your code and the use of keyboard to be able to interact with the code at a specific location.
for i=1:2:m-1
for j=1:2:n-1
if i == 505 && j == 460
keyboard % Now you can step through the "do stuff" below
end
% do stuff
end
end
As a side note, a REALLY useful debugging tip is to actually set dbstop to be triggered when ANY error is thrown.
dbstop if error
This will set a breakpoint right where any failure occurs. You can then use all the editor debugging tools or debugging commands (dbup, dbdown, dbstep, etc.) to go to where the real issue lies and look at the current state.
I have recently started using MATLAB without GUI by starting matlab with -nodesktop option and it is considerably faster.
However presently I have no way to debug a .m script in non gui mode. I have to open the default matlab editor every time I have to debug.Has anyone figured out a way to do it?
Thanks in advance
I am using Ubuntu Linux, in case that helps.
To set breakpoints with the command line, dbstop is the tool (plus dbclear to clear breakpoints and dbstatus to list them).
There are presently 17 different forms to dbstop, which allow you to specify various combinations of:
The M-file in which to stop
Line number
Sub-function
Conditional to an arbitrary expression. For example,
dbstop in myFun.m at 224 if ~exist('x','var')
At any run-time error (dbstop if error)
At a specific error (e.g dbstop if error myFun.m:barErrorId)
At any warning (dbstop if warning) or specific warning
If NaN or Inf are encountered (dbstop if naninf)
See the documentation for dbstop for details and good examples.
Also get used to dbcont (or F5), dbstep (or F10), dbquit (Shift+F5), dbstep (also dbstep in, dbstep out), dbstack (to see where you are and how you got there). The keyboard shortcuts may be different outside of Windows.
Far less used, but still very useful are dbup and dbdown, which allow you to switch workspace context (memory stacks).
See the summary of functions and a list of examples and how-to pages in the MathWorks page on Debugging.
Related to the "db" functions is checkcode, which will check your code for possible problems before you even run it. This is a nice substitute for the red squiggly underlines that you would get in the MATLAB Editor.
Once you get a hang of dbstop and it's syntax, you won't often need to insert a keyboard into your code, but it's always an option.
Try placing the keyboard command in your code to insert a breakpoint. When the keyboard command is reached, MATLAB will drop into an interactive prompt that you can use to inspect variables. For example:
x = rand(10,10);
y = rand(10,5);
z = x * y;
keyboard; % you can interactively inspect x, y, z here
z = sort(z);
To leave keyboard mode, you can type dbquit to exit the program, or return to continue executing the program.
Another trick is to turn on dbstop if error which will automatically drop you into an interactive prompt whenever your code crashes.
You can use MATLAB -Dgdb if that helps. This sets gdb as the debugger. You will need to be familiar with gdb of course.
Once you do that, use the standard gdb commands to debug it.
EDIT
My mistake. Above won't work for M-Files. (Not having MATLAB to try things out is a pain :)
MATLAB has a pretty good set of debugging commands you can use from the commandline. If you insert keyboard commands in your MATLAB code, you can then use the commands.
You can use MATLAB's editor debug button to debug within MATLAB environment
I want to force the current execution line to a specific line in the same function, possibly skipping intermediate lines. All my old school debuggers had this feature, but I can't find it in eclipse. Is there a way to do it without changing code?
The first two answers seem to miss the topic, unless it is me not understanding the question.
My understanding, a feature I searched myself, is that you want to skip a number of lines (when stepping in code) and set the program counter (to take assembly vocabulary) to the given line. It might be interesting to skip some costly object creation, see some error situations, etc. I used to do that in Visual Studio (C or C++ code).
I haven't found that in Eclipse, nor in NetBean. It might be a limitation of JVM, or an enforcement of some policy...
The Run to line command execute, of course, all lines between the current execution position and the designated one.
I too have long sought this feature, and "Run to line" is not the same thing.
This may well be a limitation of the JVM. Java does not implement goto, though it does have jump statements, like break and continue. Those are at the block level however. If this is a JVM limitation, my guess is that it is more likely due to the security architecture. Tight control of the program counter is debilitating for interlopers, like viruses -- and sadly debuggers.
I think that is not possible in Java. The only feature that allows you to "step back" is using "drop to frame", which takes you back to the first instruction of the current frame. At least I haven't seen any debugger with this specific functionality, but I haven't been able to find on the net why is it so...
I know the debugger in Visual C allows to change to pointer. I will keep on searching, maybe at least we will know why is like this, but it seems to be some kind of design limitation.
Feature request saying it is not possible
In https://bugs.eclipse.org/bugs/show_bug.cgi?id=287795 (credits to Amitd) Darin Wright says it is a limitation of the underlying Java debugger:
Currently, this is not possible with the Java debugger as the native debug interface does not provide the ability to move/set the program counter arbitrarily.
C / C++
CDT supports it however (tested on Neon, Ubuntu 14.04). Right click on the line you want to go to, and select either:
"Move to line": jump to line and break there
"Resume at line": jump to line and continue execution from there
This also serves as further evidence that there is an underlying Java limitation, as Java tends to be more feature rich in Eclipse, and those menu entries are not present in Java next to "Run to line" (which does not skip execution of lines).
This test program prints 0 if you jump the line i = 1:
#include <stdio.h>
int main(void) {
int i;
i = 0; /* Break here. */
i = 1;
printf("%d\n", i); /* Jump to here. */
}
"Run to line" appears to need the program to be running and in a paused state to use. The other option is to set a breakpoint for that line when running in debug-mode.
Double-click far-left vertical bar in the source pane on the same line to add a breakpoint; or,
Select the line and go to Run > Toggle Breakpoint.
At least, this is in Eclipse 3.3.2.