Tag: debugger

Entries for tag "debugger", ordered from most recent. Entry count: 3.

Warning! Some information on this page is older than 5 years now. I keep it for reference, but it probably doesn't reflect my current knowledge and beliefs.

Pages: 1

# The Importance of Good Debugging Tools

05:29
Thu
28
May 2015

Robert L. Glass wrote an interesting article "Frequently Forgotten Fundamental Facts about Software Engineering". While I am aware he is far more experienced than me and he has sources to backup his opinions, I dare to disagree with following paragraph:

T1. Most software tool and technique improvements account for about a 5- to 30-percent increase in productivity and quality. But at one time or another, most of these improvements have been claimed by someone to have "order of magnitude" (factor of 10) benefits. Hype is the plague on the house of software.

I think that having good tools is one of the most important (and sometimes underrated) factors in programmers' efficiency. From comfortable chair, through fast desktop PC, big monitors, fast Internet connection, to good software, including IDE (editor, compiler, debugger etc.) and auxiliary applications (like Total Commander for file management) - they can all make big difference in how developers feel about their job and how fast the work is going.

Of course, "tools" is a broad term. If by choosing good tools we mean changing used programming language or libraries in the middle of the project, then sure it is usually a bad idea. Writing a script to automate some task that can be done manually in just few minutes or even an hour is usually not worth doing as well.

But what is always worth investing time and money in (either buying or developing your own, learning to use them) are tools that help with debugging. As debugging is the hardest and most time consuming part of programming, any improvement in that process can make as big difference as between minutes and weeks - often in the most critical time, close to the deadline.

So in my opinion, being able to interactively debug executing program (or its trace) - to setup a breakpoint and preview current value of variables (as opposed to relying only on some debug text prints, analyzing logs or some command-line tools) is an absolute minimum to be able to call any programming environment reasonable, mature and eligible to write any serious software in it. If you are the one who writes a program and you have to treat that program as a black box while it is running, without a possibility to peek inside, then something is wrong. AFAIK that is the case with some technologies that deploy program to a server or an embedded device.

How is it in graphics programming? John Carmack once tweeted:

gl_FragColor.x = 1.0; is the printf of graphics debugging. Stone knives and bearskins.

While I share his frustration with such primitive methods of debugging, the reality of today's GPU programming is not all that bad as we could only render red pixels to see any debug information. NVIDIA Nsight offers debugging of a GPU, and so does Intel Graphics Performance Analyzers (GPA). Finally, there is a vendor-agnostic debugger for DirectX developed by Microsoft. Originating from Xbox (that is where its name comes from - Performance Investigator for Xbox), PIX used to be available for free as a standalone application. Recently, they have integrated it as part of Visual Studio called Graphics Diagnostics. It was available in commercial versions of Visual Studio only and not in free Express edition (very bad news for all amateur DirectX game developers), but finally they shipped it for free together with the new, fully-functional Visual Studio Community edition.

With these tools, there is no explanation for whining "nothing renders and I don't know why" - just go debug it! :) The future also looks bright. DirectX 12 will offer Debug layer. Vulkan also claims to support debugging tools and layers and LunarG company even started working on such tool - GLAVE.

Comments | #debugger #software engineering Share

# Type Visualization in Visual Studio 2012 Debugger

19:14
Tue
23
Apr 2013

When you code in C++ and you have your own library of data types, especially containers, it would be nice to be able to see it in the debugger formatted in some readable way. In Visual C++/Visual Studio, there used to be a special file autoexp.dat designed for this purpose, as described in "Writing custom visualizers for Visual Studio 2005". But it had weird syntax and poor error reporting.

Now in Visual Studio 2012 there is a new way of defining debugger visualizations for native data types, called Native Type Visualization Framework (natvis). All you need to do is to create an XML file with ".natvis" extension following special format and place it in directory: %USERPROFILE%\Documents\Visual Studio 2012\Visualizers. Full documentation of this format is on this single MSDN page: "Creating custom views of native objects in the debugger". See also "Expressions in Native C++" and "Format Specifiers in C++".

For example, if you have a singly linked list:

template<typename T>
class CLinkedList {
   // ...
    struct CNode {
       T Value;
       CNode* Next;
    };
    size_t Count;
    CNode* Head;
};

Default visualization of a 3-element object in the debugger would look like this:

But if you create following natvis file:

<?xml version="1.0" encoding="utf-8"?>
<AutoVisualizer xmlns="http://schemas.microsoft.com/vstudio/debugger/natvis/2010">
   <Type Name="CLinkedList&lt;*&gt;">
       <DisplayString>{{Count = {Count}}}</DisplayString>
       <Expand>
           <Item Name="[Count]">Count</Item>
           <LinkedListItems>
               <Size>Count</Size>
               <HeadPointer>Head</HeadPointer>
               <NextPointer>Next</NextPointer>
               <ValueNode>Value</ValueNode>
           </LinkedListItems>
       </Expand>
   </Type>
</AutoVisualizer>

Next time you start debugging (restarting Visual Studio is not required), same object will be shown as:

Besides extracting single fields from objects, evaluating whole C++ expressions and formatting values into a string for summary of whole object, this framework is able to visualize following data structures:

Comments | #visual studio #debugger #c++ Share

# How to Make Visual Studio Debugger not Step Into STL

22:49
Fri
10
Feb 2012

It is annoying when you debug your C++ code in Visual Studio, want to step into your function, but the debugger enters source code of some STL container or string. For example, in the following code you will first enter std::basic_string constructor, then std::vector operator[] and then body of MyFunction.

MyFunction(std::string("abc"), myVector[0]);

It turns out there is a way to disable stepping into certain code, using regular expressions. To do this:

  1. Run Registry Editor (regedit.exe).
  2. Navigate to the key appropriate to your version of Visual Studio or Visual C++. "VCExpress" is for free Visual C++ Express, while "VisualStudio" is for commercial Visual Studio. Number is product version. Additional "Wow6432Node" should be used when working in 64-bit Windows. For example:
    • Visual C++ 2005 Express in 32-bit Windows: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VCExpress\8.0\NativeDE\StepOver
    • Visual Studio 2005 Professional in 32-bit Windows: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\8.0\NativeDE\StepOver
    • Visual Studio 2008 Professional in 64-bit Windows: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\9.0\NativeDE\StepOver (for version 2008 it's 9.0 not 8.0, the article linked below is wrong!)
    • Visual Studio 2010 Professional in 64-bit Windows: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\10.0\NativeDE\StepOver
  3. Create new String Value with any name and a value containing regular expression to match against identifiers you want to exclude, like "std\:\:.+" for all identifiers from STL namespace (including members of std::string, std::vector and so on). I assume you know the syntax of regular expressions.
  4. In Visual up to 2008, it starts working after you start new debug session (e.g. with F5). In Visual 2010, you have to restart whole IDE.

Here is the full story:

In May 2007 I asked the question on forum.warsztat.gd and written this blog entry (in Polish). Now I've also found this article: How to Not Step Into Functions using the Visual C++ Debugger, Andy Pennell's Blog and this StackOverflow question: Is there a way to automatically avoiding stepping into certain functions in Visual Studio?

From that I've learned that Visual Studio 6.0 used autoexp.dat file, while new versions use Windows registry.

Rules entered in registry can be suffixed with case-insensitive "=NoStepInto" (which is the default) or "=StepInto".

Aside from regular expression syntax you can use additional special codes: \cid (identifier), \funct (function name), \scope (class or namespace, like myns::CClass::), \anything (any string) and \oper (C++ operator).

Double backslashes you can meet on some web pages come from the REG file format, where backslash must be additionally escaped, like "\\:". If you enter regular expression straight into regedit, it should be "\:".

NEW: In Visual Studio 2015, it is completely different. To add such entry:

  1. Open file: c:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\Packages\Debugger\Visualizers\default.natstepfilter
  2. To be able to modify it, you must overcome two obstacles: 1. It's in Program Files directory, so you have to do it as administrator. 2. The file is Read-Only, so you need to disable this attribute.
  3. Add following entry to this XML file: <Function><Name>std::.+</Name><Action>NoStepInto</Action></Function>

Comments | #c++ #visual studio #debugger Share

Pages: 1

STAT NO AD
[Stat] [STAT NO AD] [Download] [Dropbox] [pub] [Mirror]
Copyright © 2004-2017