In Visual Studio for my native C++ program I want to get a plot of some variables during debug. Mostly I use textual representation of the objects by editing autoexp.dat. But for some of the variables it is better to have a plot rather than having values in textual form.
So far I have used a function plot(const void* address,const char* type) , and called it from Immediate Window giving the variable address & the type, and internally casting it to proper type.
But this method has two disadvantages:
First is that, function overloading almost never works when calling a function from debugger (so I had to pass type as a second parameter), and the function call occasionally crashes, though it works perfectly when called from within code.
Second is, instead of writing a C++ function for plotting, I am interested to have a scripting language (like autoexp.dat or a VBScript) to give the internal data of the C++ object without writing any wrapper, so that I can use the script to store the data in a file or plot it.
In general I am interested to have something like Matlab or Ch IDE, where I can plot certain variable externally when the program is at a debug break.
Since VS 2005, Visual Studio has included Visualizers, which could almost have been designed specifically for your problem. MSDN explains the concept better than I can:
Visualizers are a new component of the
Visual Studio debugger user interface.
A visualizer creates a dialog box or
other interface to displays a variable
or object in a meaningful way that is
appropriate to its data type. For
example, an HTML visualizer interprets
an HTML string and displays the result
as it would appear in a browser
window, a bitmap visualizer interprets
a bitmap structure and displays the
graphic it represents, and so on. Some
visualizers allow you to edit as well
as view the data.
See here for a tutorial on how to write one.
You can plot variables in real-time charts with NetDebugPlot and NetDebugLog.
#include "NetDebugLog.h"
NetLog(myvar);
NetLog("test", myvar2);
As others have noted, I'm not sure exactly what do you wish to plot. I usually understand, when someone says he wants to "plot something", he usually means some array with numerical values.
If this is true in your case, Intel's Array Visualizer is maybe of some help. It can be downloaded freely, it integrates into visual studio, and you can use it in two ways: as a standalone application or while debugging ("while in some breakpoint") so you can plot array values "while program is running".
Could you use gnuplot for this? Spit out the data you want to plot as debug prints, and then while you're sitting at a breakpoint, copy it to an external file and run it through the plotter.
Related
I'm new to c++ debugging and LLDB. I'm using VSCode with its c++ adapter, LLDB as the debugger, and bazel as the build system. My application deals with manipulating images. The application runs quickly but debugging it is very slow. That's because once I've loaded the images into memory, it takes about 20 seconds to a minute to step through each line. My assumption is that the raw images are too much for the debugger. If I use a small image, then I'm able to step through the code quickly inside the debugger
My question is: is there a way to tell the debugger to ignore the image loaded variables? Or perhaps to lazy-load the image variable data? I'm more interested in the other variables such as the matrices.
The underlying debugger, lldb, doesn't fetch any variables unless explicitly asked. It's always the UI that requests variable values.
In Xcode, if you close the Locals View, Xcode won't ask lldb to fetch variables. That does speed up stepping in frames with big local variables.
Then if you need to keep an eye on one or two of the variables while stepping you can use tooltips or the debugger console to print them on demand. You can also set up target stop-hooks in the lldb Console and use them to auto-print the variables you are tracking.
Some UI's also separate the "Locals" view from the "Watched Expression" view, so you can close the former and put the variables you need to see in the latter.
I don't know if VSCode allows you to close the Locals view, but if it does that might be a way to handle this problem.
Sometimes when using the data viewer in debug mode in Visual Studio 2010 (C++), I cannot see the data. I can see the data of many other variables, but not the one shown below. The element below is an array. How do I get rid of the "(error)" messages and see the data?
Update: I wrote a member function called "view". If I jump into the function call, the debugger works fine and I can see all the class variables. So maybe this is an issue with the debugger following pointers.
Is your object "test" one of standard STL class (vector, set, etc..)?
If yes, usually you should get also size in debugger tooltip - and this looks like corrupted autoexp.dat file.
If you did some modification in autoexp.dat, then try to revert it back and check if this helps.
I'm using visual studio for kernel debugging. Yes, I know all the tutorials say to use WinDbg, but visual studio is actually spectacular now for Kernel debugging. It's a more recent development.
When I have a pointer in the watch window, assuming it is an array, I would like to see multiple items in its list at once as a drop down. Normally in Visual Studio you would add ",AMOUNT" after the pointer to get multiple items, but this does not work when in kernel debugging mode.
Is this option available?
[Edit] As requested, I have attached an example image. In the watch window I have included multiple attempts to access the data in the "ProcessPath" variable.
During Kernel Mode Debugging, Watch window appears to work through WinDBG expression evaluator. That is, it works pretty much the same as WinDBG's Watch window. Therefore, your question is not really Visual Studio related, but rather it boils down to WinDBG's watch.
This is why ,amount syntax will result in showing amount as result - WinDBG treats , as "evaluate and discard", just like c++ does. This also explains why you prepend variables with $! which is WinDBG syntax for local variables.
While WinDBG supports quite a bit of c++ syntax, it will unfortunately fail to recognize c++ cast-to-array syntax such as (char(*)[4])$!ProcessPath (by the way, this works when debugging a usermode target in in VS debugger).
I have not found a single way to cast to array in WinDBG. It seems the only workaround available is to add specific elements of array to watch, like
ProcessPath[0]
ProcessPath[1]
ProcessPath[2]
ProcessPath[3]
ProcessPath[4]
ProcessPath[5]
ProcessPath[6]
ProcessPath[7]
ProcessPath[8]
I have prepared a program launcher in C++ (the only language I know), which accepts strings as program trigger.
But however hard I try I'm unable to give it a GUI like look; using graphics.h's graph functions creates graphics but in cmd like window.
All I need is a small widget/window like thing that sits on the desktop where a user can type the command string (and error messages can be displayed as usual).
Can I get a code snippet for such a widget/window?
The input string may be copied to a .txt file and my prog will read it from there.
P.S.- I'm a beginner & rookie so please avoid complex alternatives.
Well, one of the easiest options in my opinion is to use .NET Framework:
http://10rem.net/blog/2010/03/04/my-first-windows-cplusplus-application-in-ages-hello-world-in-win32-with-visual-cplusplus-2010
http://msdn.microsoft.com/en-us/library/bb384845.aspx
When I'm debugging C++ mixed (managed/unmanaged) projects in Visual Studio 2005, I often get weird data from the debug watches, like below :
(btw, the variable i_processName is a const std::string & )
alt text http://img175.imageshack.us/img175/3561/43419953av1.jpg
Note that the variable actually holds valid data - if i print it to stdout, the printed string is just fine, thanks for asking.
The simpler types of data (e.g. ints) (usually?) get their correct values shown.
Did this ever happen to you too?
This is a major PITA when debugging, so ... any ideas on how to make the watches show the correct data, or what's causing this?
Debug display of custom types (this includes the STL) depends on the file autoexp.dat located in the <install_path>\Common7\Packages\Debugger folder. Make sure that yours matches your library version and that an older version of this file hasn't been kept around (when upgrading for example).
Note that you can also write your own visualizers for other types, more info here and here. This is a major time saver for complex projects, well worth the (small) effort put into writing custom visualizers.
Yes, i see this problem in my debuger, in my case its connected to Unicode vs NonUnicode.
Looks like your debugging symbols are incorrect.
Check the modules debug window (menu: Debug>Windows). Check that modules you are debugging have "Symbols loaded." listed under the Symbol Status column. Check that the Symbol File listed is the file you think it should be. You can right click a module and get more info about how VS loaded the symbols and you can reload them as well.
If you're having symbol loading problems you can set paths and other settings under Tools>Options>Debugging>Symbols.
A bad call stack can cause issues like this as well. Make sure the stack doesn't have any entries like "the stack may be incorrect for this point...". Does it?
It also can be something odd with Visual Studio confusing native and manged data types in the visualizer, but I doubt it. The popup in your screen shot looks like the debugger know what the variable is.
One thought -- the STLPort implementation of std::string uses a split buffer implementation. It has a small static buffer (I want to say 14 characters) and a pointer to a char array. One of these will be invalid and the other will contain the string data, depending on the length of the stored string. If you're using STLPort or a similar implementation, your string visualizer might be looking at the wrong buffer, which happens to contain junk data.
I beleive that Aardvark is probably onto the correct answer. If i remember correctly when you are compiling mixed mode, the compiler will turn as much of the C++ code it can into code that runs on the CLR, and consequently memory that is owned by the CLR. My geuss is that the debugger is confused about where the string is held - unmanaged or managed memory.
This is a bug that has been in the Visual Studio debugger since forever and still occurs in Visual Studio 2019.
It is random.
Sometimes making a code change and recompiling resolves the problem, and sometimes it doesn't.