Bug Babble : Bugs

Simple VS Addin (updated)

SteveJS — Wed, 21 Dec 2005 22:41:00 GMT

Back during the PDC for Whidbey I wrote a post about Creating a Simple Addin. Recently I was looking to update it and found a horrible bug in it. First, here is the corrected code:

public void OnConnection(object application, ext_ConnectMode connectMode, object addInInst, ref Array custom)
{
    _applicationObject = (DTE2)application;
    _addInInstance = (AddIn)addInInst;
    _debuggerEvents = _applicationObject.Events.DebuggerEvents;
    _debuggerEvents.OnEnterBreakMode += new _dispDebuggerEvents_OnEnterBreakModeEventHandler(DebuggerEvents_OnEnterBreakMode);

}

private DebuggerEvents _debuggerEvents;
private System.Collections.Generic.Queue<EditPoint> epQ = new System.Collections.Generic.Queue<EditPoint>();
void DebuggerEvents_OnEnterBreakMode(dbgEventReason Reason, ref dbgExecutionAction ExecutionAction)
{
    TextDocument td = (TextDocument) _applicationObject.ActiveDocument.Object("TextDocument");
    EditPoint ep = td.Selection.ActivePoint.CreateEditPoint();
    ep.SetBookmark();
    epQ.Enqueue(ep);
    if (epQ.Count > 5)
    {
        epQ.Dequeue().ClearBookmark();
    }

}

I've changed a couple of things. I now create the Editpoint first and use it to set the bookmark rather than setting the bookmark on the selection then creating an editpoint. This removes that possibility that I save a different place then where I set the bookmark.

The more important issue is I keep a member variable for _applicationObject.Events.DebuggerEvents. Why? Because it keeps that event provider from getting garbage collected. I had made the assumption that the lifetime of _applicationObject.Events.DebuggerEvents would be strictly tied to the DTE object, and managed by automation. That is not the case. The way this bug manifests is pretty ugly since the Addin works as expected for a while, until the Event Provider (_applicationObject.Events.DebuggerEvents) is collected and Finalized, at which point the events just stop coming.

I wasn't sure if this was by design or not. However, I found this KB article: Visual Studio .Net events being disconnected from add-in, so I am going with it being by design.

Naming threads in Win32 And .Net

SteveJS — Tue, 20 Dec 2005 08:25:00 GMT

When you are debugging an application with multiple threads it can be handy to have a better name than just the thread id. This is simple to do in managed code. There is a property on the Thread object that you can set. It is also possible to do this for native code. However, there is simply no way you will ever discover it unless someone points you to the difficult to find docs. I knew about the feature and still missed the docs the first time I looked for them!

For completness, here is the managed version: Setting a Thread Name (Managed).

The more interesting one is the native version: Setting a Thread Name (Unmanaged) (There is a typo in the documentation's code; 'except' should be '__except'. I've included a corrected copy below.)

The native method of setting the thread name is implemented by raising an SEH exception that is continued. If you go to the docs on RaiseException you'll see part of the reason for this strange mechanism. An attached native debugger will get a 'first chance' notification of the exception. Raising an exception is precisely what you need to do to get the native debugger's attention. The one raised here (0x406D1388) is recognized by VS (and WinDbg).

Note: If anything in your process installs a vectored exception handler, that handler will not be called on this exception code when the VS debugger is attached. The VS debugger always handles this exception code and continues execution, preventing any further handlers. In WinDbg you can go to Debug/Event Filters and set the "Visual C++ exception" to be disabled. With that setting, your vectored exception handler will get a shot at 0x406D1388 while WinDbg is debugging it.

//
// Usage: SetThreadName (-1, "MainThread");
//
typedef struct tagTHREADNAME_INFO
{
   DWORD dwType; // must be 0x1000
   LPCSTR szName; // pointer to name (in user addr space)
   DWORD dwThreadID; // thread ID (-1=caller thread)
   DWORD dwFlags; // reserved for future use, must be zero
} THREADNAME_INFO;

void SetThreadName( DWORD dwThreadID, LPCSTR szThreadName)
{
   THREADNAME_INFO info;
   info.dwType = 0x1000;
   info.szName = szThreadName;
   info.dwThreadID = dwThreadID;
   info.dwFlags = 0;

   __try
   {
      RaiseException( 0x406D1388, 0, sizeof(info)/sizeof(DWORD), (DWORD*)&info );
   }
   __except(EXCEPTION_CONTINUE_EXECUTION)
   {
   }
}

FuncEvil, the Clipboard, and Deadlocks

SteveJS — Fri, 09 Dec 2005 10:22:00 GMT

Mike Stall has a great post that, for a debugger dev, is the moral equivalent of sticking a fork in a toaster. The basic problem he addresses is that once you are stopped in the debugger the UI for your application will no longer paint. What if you need to see something on that UI? If you like to live on the edge, Mike’s Evil trick to render UI when stopped at a breakpoint is the answer for you. Unfortunately, you need to be stopped on the UI thread for it to work. Pumping messages on another thread will not unblock the UI to paint. Even more unfortunate is that switching threads in the debugger won’t help. Function evaluation when debugging managed code requires you to be at a reasonable point on the thread. It is very unlikely you will randomly be at such a point, unless you stopped on the thread in question. You can see the result I got when I stop on another thread, then switched to the UI thread:

?System.Windows.Forms.MessageBox.Show("pump")

Cannot evaluate expression because a thread is stopped at a point where garbage collection is impossible, possibly because the code is optimized.”

Now don’t let this dissuade you from how useful this very, very, very dangerous trick can be. Sometimes playing with fire is useful.

Not rendering the UI is only one problem that can happen due to the debugger stopping a process. A really bad problem that lack of message pumping can cause is clipboard deadlock. The real problem is due to delayed rendering, which requires the app that copied to the clipboard to be live. You can read about delayed rendering on the MSDN Clipboard Operations page. The basic problem is that the application you are debugging owns the clipboard, and other apps need it to respond to messages to get the contents of the clipboard. You can see this by creating a trivial winform app with a button and a RichTextbox:

(Note you need to use a RichTextBox here … a normal TextBox will actually copy the contents to the clipboard rather than using delayed rendering.)

First set a breakpoint in the button handler. Then select the “Copy me at your own Risk!” text and copy it to the clipboard with Ctrl-C. Now hit the button. Nothing is wrong yet. However if you go to any application and hit paste that application is now hung, and will remain so until you continue from the breakpoint. If you hit paste in the debugger you’ll deadlock that too without any way to continue from the bp. Clipboard deadlock has hit me few a times composing mail while stopped at a breakpoint. Using the trick that Mike outlines does free the applications waiting for your winform app to provide the clipboard data.

If you do not understand why func eval is evil I must end by pointing you to Mike's older post Func-eval is evil, and GreggM's more recent post Func eval and System.Windows.Forms.Form. Func Eval is powerful, and with great power comes a bunch of power to shoot yourself in the foot. Be careful using func eval.

Change Debugger behavior with Attributes

SteveJS — Sun, 04 Dec 2005 00:54:00 GMT

Certain metadata attributes modify the stepping, breakpoint, and callstack behavior of the VS managed Debugger. This is useful if you are creating an interpreter, language runtime, or a tool that modifies the code in a managed assembly. There are three flavors of these attributes that affect execution control. Each behaves slightly differently, and I always forget which does what, so I'm recording it here for my own reference as well.

The code below shows examples using all three attributes: DebuggerStepThrough, DebuggerHidden, and DebuggerNonUserCode. The example also shows the hidden line directive. I've inlined the explanation as comments in the code so it can travel with the example. This general area of writing tools that interact with the debugger has been well explored on Mike Stall's blog:

#line hidden and 0xFeeFee sequence points

How can I debug Just My Code?

Debug support for arbitrary state-machines

using System;

// This example shows the use of the three debugger attributes
// that modify the runtime behavior of the VS debugger.

// The motivating example is part of an AOP (Aspect Oriented Programming)
// implemenatation.
// The concepts around AOP are pretty interesting, but for this
// example it is sufficient to know that anything called a 'Thunk'
// is something added by the tool that is of no interest to the user.

// The example code is what a weaver that uses C# as a backend could
// send to the compiler to accomplish the hiding of
// JoinPointThunks, and the calls to those thunks.

// Try stepping through this with this option on:
// Tools/Options/Debugging/General/Enable Just My Code
// Then try the same with the option off.

// You'll see that each attribute creates a slightly different end user
// behavior and slightly different ease of debugging for yourself
// when you need to debug the glue code you are hiding from the user.

class DynamicallyAddedUserCode
{
    public static void bar()
    {
        Console.WriteLine("Hello advice\n");
    }
};
class Weaver
{
    [System.Diagnostics.DebuggerStepThrough]
    public static void ExampleJoinPointThunk_withDebuggerStepThrough()
    {
        //_________________________________________________________________
        // Tools/Options/Debugging/Enable Just My Code ON:
        //CALLSTACK view: Frame is viewable
        //BP: Will hit bp.
        //STEPPING: Will not stop inside due to a step.
        // (Even from bp hit! Any step is a step out.)
        // Step in will land inside called methods.
        //_________________________________________________________________
        // Tools/Options/Debugging/Enable Just My Code OFF:
        //CALLSTACK view: [External Code] frame.
        //   Real frame is viewable by selecting 'Show External Code'
        //   in Callstack window.
        //BP: No bp will set or hit. A warning is provided,
        //STEPPING: Will not stop inside method (step in or step out)
        // A step in will land in called methods.
        //_________________________________________________________________
        DynamicallyAddedUserCode.bar();
        int thisGoesTo = 11;
    }
    [System.Diagnostics.DebuggerHidden]
    public static void ExampleJoinPointThunk_withDebuggerHidden()
    {
        //_________________________________________________________________
        // Tools/Options/Debugging/Enable Just My Code ON:
        //CALLSTACK view: Frame is completely hidden.
        //BP: A Bp will set with no error, but will not hit!
        //stepping: A Step in will land in called methods.
        //_________________________________________________________________
        // Tools/Options/Debugging/Enable Just My Code OFF:
        //CALLSTACK view: Frame is completely hidden. (i.e. No [External Code])
        //BP:Warning provided, no bp will set or hit.
        //STEPPING: Will not stop inside method (step in or step out)
        // A step in will land in called methods.
        //_________________________________________________________________
        DynamicallyAddedUserCode.bar();
        int thisGoesTo = 11;
    }
    [System.Diagnostics.DebuggerNonUserCode]
    public static void ExampleJointPointThunk_withDebuggerNonUserCode()
    {
        //_________________________________________________________________
        // [Same as normal code.]
        // Tools/Options/Debugging/Enable Just My Code ON:
        //CALLSTACK view: Normal view, callstack is viewable.
        //BP: A bp will set and hit.
        //STEPPING: Step as normal.
        //_________________________________________________________________
        // [Same as Debugger StepThrough]
        // Tools/Options/Debugging/Enable Just My Code OFF
        //CALLSTACK view:[ External Code] frame.
        //   Real frame is viewable by selecting 'Show External Code'
        //   in Callstack window.
        //BP: Warning provided, no bp will set or hit.
        //STEPPING: Will not stop inside method (step in or step out)
        // A step in will land in called methods.
        //_________________________________________________________________
        DynamicallyAddedUserCode.bar();
        int thisGoesTo = 11;
    }
};
class Program
{
    static void foo()
    {
#line hidden //this emits a Sequence Point with line = 0xFeeFEE
        //Imagine these hidden areas were added dynamically
        Weaver.ExampleJoinPointThunk_withDebuggerStepThrough();
#line default
        int theone = 1;
#line hidden
        Weaver.ExampleJoinPointThunk_withDebuggerHidden();
#line default
        int volume = 11;
#line hidden
        Weaver.ExampleJointPointThunk_withDebuggerNonUserCode();
#line default
        int answer = 42;
    }
    static void Main(string[] args)
    {
        foo();
    }
}

// The #line hidden directive places 0xFeeFee sequence point in the line
// information. The 0xFeeFee sequence point tells the debugger to continue
// stepping. It is not necessary unless a step can end at the location.
// If you are writing a compiler and emitting your own debug information,
// then it is often possible to simply omit the line info for code that would
// be marked hidden. If you decompile the above code with ILDasm /Linenum you
// will see an example of that strategy.
// However there are cases where it is important to use the a hidden sequence
// point. Any place where a branch instruction lands must use a hidden sequence
// point if you do not want the debugger to stop there.
//
// The motivating example for this is having all exit points from a Try block
// branch to a single leave instruction. If you produce that type of codegen
// you will need to use 0xFeeFee to create reasonable stepping behavior.

Netmodules: Sort of like a lib

SteveJS — Mon, 28 Nov 2005 06:19:00 GMT

I first ran into netmodules before VS 2002 was shipped. The netmodule gave me precisely what I asked for, without actually solving my problem. I wanted to use multiple languages (C#, and C++ /clr) in a single assembly. It turns out a single assembly can be multi-module. Multi-module means a single .Net assembly is spread across multiple win32 dlls. What I really wanted was a single module assembly written in multiple languages. Netmodules couldn't solve my problem back then, but with the VS 2005 C++ linker they can now.

Check out JuFeng's articles for some more in depth coverage, and an explanation why you might want a multi-module assembly:

MultiModule Assemblies

Netmodule vs. Assembly

Since JuFeng's examples didn't show how to create debug info I thought I'd make an updated example here.

Here's a quick example with a multi-module assembly:

From the Visual Studio 2005 Command Prompt:

C:\blog\linkexample>vbc /target:module /debug+ b.vb

C:\blog\linkexample>csc /debug+ /addmodule:b.netmodule a.cs

C:\blog\linkexample>devenv /debugexe a.exe

Check out the modules window:

And the callstack window:

To get a single file assembly I'll need to recompile the cs file into a netmodule then use the c++ linker.

C:\blog\linkexample>csc /addmodule:b.netmodule /target:module /debug+ a.cs

C:\blog\linkexample>link /entry:fooCS.Main /out:theone.exe /subsystem:console /debug a.netmodule b.netmodule

C:\blog\linkexample>devenv /debugexe theone.exe

Now check out the modules window:

And the callstack window:

XSLT debugging in Visual Studio

SteveJS — Thu, 17 Nov 2005 10:40:00 GMT

Visual Studio is a big tool. It's easy to miss some useful features. Hopefully the XSLT debugger won't get missed. If you want to learn how to use XSLT debugging take a look at Neetu Rajpal's msdn article Introducing Xml tools in VS 2005. Below you can see the debugger in action as an xslt transform is being applied to some XML.

(Please excuse the nonsense XSLT I use in the example. I haven't had a chance to play around with XSLT for quite some time.)

XSLT debugging is interesting to me because much of it is the managed debugger. XSLT is compiled to msil, and the managed debugger is used to provide things like breakpoints and stepping. You can see this by opening the modules window. You'll see in the last column that the process is a managed process called the Microsoft.XSLDebugProxy.exe, and there will be some modules loaded with names like System.Xml.Xsl.CompiledQuery.1. All of the debugger windows work as expected: callstack, locals, immediate, threads, modules. You can see below the callstack for my nonsense example:

However! Go to the callstack window and right click to get the context menu. There will be an item called Show External Code. Pick that and you get to see much in the callstack window that was hidden before. The grey colored frames are because there is no debug info (pdb file) for that assembly, which is why those frames were marked as 'External Code' before. The CompiledQuery frames were hidden because the XSLT compiler placed an attribute on them to tell the debugger they were not of interest. With the expanded view you can now see the compiled query and the code that dispatched it.

However, while that is interesting it is unlikely to help you get at a bug in your XSLT. The Locals window however appears to be one of the more useful windows, that can help you see what is happening as the transforms are applied.

Perf Awareness is not Premature

SteveJS — Mon, 07 Nov 2005 02:38:00 GMT

I've found myself adding a timer to each of the unit test frameworks I use so I can see how long my tests take. I am not trying to do anything complex. I just want to be aware of the perf. The same way pass and fail are visible, 1ms vs 90ms is visible.

Premature optimization rightly has a bad rep. Creating complex code where performance doesn't matter is a bad tradeoff. That's not what I'm doing here. I am not trying to code for perf. I'm trying to be perf aware. If the test is fast I'm certainly not going to use that as an excuse to start changing code. If it's slow, I know about it and I won't check in something that kills perf. Once you have a number, the real question is: How do you judge if it is fast or slow? The answer is a perf budget.

Rico Mariani has a great Designing for Performance post where he talks about using Perf budgets.

In the absence of a perf budget, spend your time getting a perf budget rather than mucking about with code. Once you have perf budgets, being aware of resource consumption makes it easier to see problems earlier. A perf problem is a bug. Fixing a bug before it gets into the source tree is always a good idea.

Checking the result of new is a bug in C++

SteveJS — Tue, 01 Nov 2005 21:20:00 GMT

At least, it is a bug in VC8. That check won't happen. Reading Larry Osterman's recent posts "What's wrong with this code, part 15" and the answers, reminded me this behavior changed in VC8. If you check the result of new in code compiled with VC8, your code is wrong. The call to new will throw. Yes, your code worked in 5.0, 6.0, (maybe) 7.0 and 7.1, but it doesn't now.

You can get the old behavior if you link with nothrownew.obj. The linker will then make every call to new in your dll (or exe) non-throwing. This is incompatible with STL, or any other code that relies on new throwing.

The only other option is to use std::nothrow placement new. Don't do that.

If you are writing code that uses no throw semantics, you probably need those same semantics from the libs you link as well. If you are linking a lib that was coded expecting new to return NULL rather than throw, the linker doesn't know that. In VC8 it will link the throwing version. Linking with nothrownew.obj tells the linker that everything needs the old, non-standard version of new that returns NULL.

What if you are using 2 libs? One that needs the non-standard new, and one that needs the standard new? If that is the case, package one in it's own dll, or change it so you have consistency on the definition of new. Don't bother trying to get the linker to do something magical. It won't. The linker makes a decision on what new means and that's it for the entire dll.

History of new through the VC's:

In VC5.0, and VC6.0 you basically got nothrow new and had to jump through hoops to get a throwing version. MFC did use a throwing version, but it doesn't throw std::bad_alloc. Also new(std::nothrow), had bugs which caused it to throw in some circumstances. For users of non throwing new, life was good. For everyone else, not so much. See this msdn article "Don't Let Memory Allocation Failures crash your lagacy STL Application" for the details.

In 7.0 and 7.1 the VC++ team attempted to do something clever. The version of new you get is controlled by the first significant header in the first obj linked. This means a large number of examples do exactly what you'd expect. It also means there are corner cases where it is almost impossible to understand what's happening. You could force a standard complying new by linking thrownew.obj.

In 8.0 the VC++ team decided to clean up many standard compliance issues. Now the C++ standard is used. Full Stop. If you want the old behavior, you must link nothrownew.obj.

Finally, I must thank Martyn Lovell for explaining the background on this issue, and clarifying some of the details. If there are any errors here they are due to me alone.

PsuedoVariables and Format Specifiers

SteveJS — Tue, 18 Oct 2005 19:27:00 GMT

The VS debugger has a history of tiny but useful features hidden in the expression evaluator. These features are like the yellow shirted ensign in star trek. They are useful, but unknown and expendable. Developer's learn about them by attending a Power Debugging talk, or buying one of John Robbins very good books.

I started blogging about some of these features recently. When I mentioned that to John Cunningham, he told me he had already blogged about these. I did a search and found something even more surprising. There's real documentation!

Pseudovariables: (This is what I was going to blog about. Goodbye series of good blog topics.)

http://msdn2.microsoft.com/en-us/library/ms164891(en-US,VS.80).aspx

You should also see these blog posts for pseudovariables in action:

Whidbey Debugger pseudo-register - $user

Devenv stealth feature, Poor Man's Profiler

Cool Whidbey debugger feature: Merge Environment

One last debugger tip

Format specifiers in C++:

http://msdn2.microsoft.com/en-us/library/75w45ekt(en-US,VS.80).aspx

Format specifiers in C#:

http://msdn2.microsoft.com/en-us/library/ms164891

Format specifiers are useful for telling the debugger how you want to display the value of an expression. In the watch window the 'Size Specifier for pointers and Arrays' is very useful. When you start using Tracepoints you'll quickly find ,x and ,d are invaluable. There are more extensive mechanisms for customizing how expressions are displayed in VS, but that is a topic for another day.

$env=0

SteveJS — Sun, 16 Oct 2005 01:18:00 GMT

Winning the award for the least understandable UI metaphor: the ability to view the environment variables in the target when native debugging. This is yet another tiny undocumented feature of the native expression evaluator in VS. $env falls under the same extravagant disclaimer from the @clk post.

Place $env in the watch window and you get … the size in bytes of your environment block.

Wow.

Far more useful is to type "$env=0", which evaluates to "0", and dumps all the Environment Variables to the output window. If you use the Immediate window "?$env=0" you get everything inline. The feature requires you to be native (or interop) debugging and to evaluate it from a native frame.

Despite the insane UI interaction, the end result is very useful information.

Assembly language survival guide (for Debugging ... not writing)

SteveJS — Fri, 14 Oct 2005 19:41:00 GMT

Knowing just enough assembly is a really powerful aid in Debugging. These are short articles that hit the sweet spot of enough information to be very useful, but not so much that it is a chore to learn:

Matt's Just Enough Assembly Language to Get By:

http://www.microsoft.com/msj/0298/hood0298.aspx

http://www.microsoft.com/msj/0698/hood0698.aspx

GreggM also has some blog posts that show very useful features and techniques in this area:

What you can and cannot trust from the debugger:

http://blogs.msdn.com/greggm/archive/2004/12/15/315673.aspx

A powerful technique for finding COM pointers on the stack:

http://blogs.msdn.com/greggm/archive/2005/08/01/446293.aspx

Getting back to the exception from an unhandled exception filter (.cxr):

http://blogs.msdn.com/greggm/archive/2004/08/25/220360.aspx

Devenv stealth feature, Poor Man's Profiler

SteveJS — Thu, 13 Oct 2005 19:15:00 GMT

This feature is unsupported. It is undocumented. If you call help desk about it nice people will say “huh?” If it breaks, people will nod knowingly and say “I told you so”. In later versions it may simply disappear. It could decay right now as I speak and explode! (maybe not.)

One more disclaimer ... it is Native Only, it does not work for managed debugging.

The @clk 'pseudo register' has been around for a while. If you have VS7.0 or greater you can use this. It is the poor mans profiler. Stick @clk in the watch window and you get a tick count. Each time you step it will be updated. Put @clk=0 in the next slot of the watch window and the first @clk will show the time (including debugger overhead) since the last stop.

But wait there's more! With the advent of tracepoints you can get @clk on steroids. Set a bp, then right click on the red bp circle and go to "When hit". In the dialog check the "Print message" check box and fill in this: {@clk},{@clk=0} $FUNCTION. Now open the output window and run. You will get a list of tickcount deltas between each tracepoint hit.

Here is an example I took for devenv rendering a callstack with 8 frames:

406298197,0 CDebugStackFrame::GetArgs(unsigned short * *, unsigned long, unsigned int)

111466,0 CDebugStackFrame::GetArgs(unsigned short * *, unsigned long, unsigned int)

6228,0 CDebugStackFrame::GetArgs(unsigned short * *, unsigned long, unsigned int)

4657,0 CDebugStackFrame::GetArgs(unsigned short * *, unsigned long, unsigned int)

5933,0 CDebugStackFrame::GetArgs(unsigned short * *, unsigned long, unsigned int)

8049,0 CDebugStackFrame::GetArgs(unsigned short * *, unsigned long, unsigned int)

5844,0 CDebugStackFrame::GetArgs(unsigned short * *, unsigned long, unsigned int)

92580,0 CDebugStackFrame::GetArgs(unsigned short * *, unsigned long,g unsigned int)

You'll notice the first tick count is meaningless, the rest give relative times. Here we can see the time between the 1st and 2nd and the time between the 7th and 8th calls took substantially more time. Looking at the callstack frames generated by those two calls each required function evaluation. I went to the callstack window and turned off 'Show parameter values'. The refresh of the callstack without function evaluation gave me some new data:

732630352,0 CDebugStackFrame::GetArgs(unsigned short * *, unsigned long, unsigned int)

3452,0 CDebugStackFrame::GetArgs(unsigned short * *, unsigned long, unsigned int)

5125,0 CDebugStackFrame::GetArgs(unsigned short * *, unsigned long, unsigned int)

5117,0 CDebugStackFrame::GetArgs(unsigned short * *, unsigned long, unsigned int)

2648,0 CDebugStackFrame::GetArgs(unsigned short * *, unsigned long, unsigned int)

5406,0 CDebugStackFrame::GetArgs(unsigned short * *, unsigned long, unsigned int)

4818,0 CDebugStackFrame::GetArgs(unsigned short * *, unsigned long, unsigned int)

5432,0 CDebugStackFrame::GetArgs(unsigned short * *, unsigned long, unsigned int)

Note the $FUNCTION is optional. Here is what I get when I remove that bit:

With Function evaluation:

1122488927,0

82541,0

4880,0

5737,0

2480,0

6899,0

4696,0

83810,0

Without function evaluation:

8114431,0

5796,0

4868,0

4858,0

2352,0

5077,0

4676,0

5413,0

So, how long is a 'tickcount'? You need to ask the hardware (QueryPerformanceFrequency) as the QueryPerformanceCounter api this uses is hardware dependent.

Also as a side note the numbers above are from a debug build of devenv running a checked version of the clr. I've had testers mock me for how slow my machine appears with a checked clr, so don't bother reading too much into those values.

Edit & Continue trick for Conditional Bps

SteveJS — Wed, 12 Oct 2005 09:33:00 GMT

Using Edit and Continue to fix a bug is handy, but don't wait until you've found the bug to start editing. One powerful technique is to use E&C when you are still trying to find the problem. Edit and Continue allows you to make any conditional bp into a normal bp. This is useful for two reasons.

First, if you only have an Express Edition this is the only way you are going to get a conditional bp for managed code. The C++ express edition does have conditional bps for native. If you have a full edition it is still useful because conditional bps are sometimes just too slow. The debugger implements conditional bps by setting a breakpoint that is always hit, then evaluating the condition on each hit. If the location you want to stop at is a cpu hot spot, it may be too slow.

Here's an example using native C++ E&C to place a fast conditional bp:

First, a normal conditional bp:

int i = 0; // Instruction Pointer starts here

while(true)

{

i++; // Conditional bp "i==10000" here, takes ~ 134ms on my machine

}

Now, using E&C (note 2 orders of magnitude are added to the condition so the time registers):

int i = 0; // Instruction Pointer starts here

while(true)

{

// Two lines below are added via E&C

if (i==1000000)

i=i; // bp here, takes 3 ms (including E&C apply)

i++;

}

Remember to delete your inline conditional bps once you are done debugging!

Is there such a thing as a good bug?

SteveJS — Wed, 05 Oct 2005 19:39:00 GMT

I was dreaming last night that Shai and I were cleaning an old apartment, when a hockey puck sized bug crawled onto Shai's hand. In real life there would have been screaming. In the dream she lifted it up so we could both look at it.

I am not an entomologist, but I'd be surprised if this was a real bug. It looked like a giant beetle with a coat of lady bug paint. Shai said there was nothing to worry about, "We want this kind of bug. It eats mice." It certainly looked big enough to handle the job. An insect that doesn't bother you and eats other vermin isn't the worst thing in the world. Attracting good insects is a strategy for pest control in organic farming. An insect is only a pest if it hurts your crop.

Is there such a vermin eating bug in software development? Maybe. First, lets decide to agree, for the rest of this blog entry, that 'bug' means flaw in your software, rather than a visible symptom. Is there a difference? You bet. If you rely on undefined behavior, that happens to be true right now, by the bug = flaw definition you have a bug. By the bug = symptom definition you do not. (BTW- Don't kid yourself, if you rely on undefined behavior you do have a bug.)

Right now, bug = flaw is any insect in reach, and bug = symptom is paying attention only to the bugs you see killing your plants. So far, these definitions are not helping
to create a category of good bugs. You obviously don't want to ship software with symptoms, and you don't want to ship software with unseen flaws waiting to crawl out from under the counter. Where might one's person's bug, be another person's useful insect?

The answer is in testing, and I can give two examples, thanks to having read Michael Feathers' Working Effectively with Legacy Code. One example is a flaw in style. Using protected data members in C++ is considered bad style because it breaks encapsulation. The root of the argument is the same as for why public data members are bad. I think of it this way: How do you write an abstraction function, or an invariant for your class if you cede control over the data? Your class either needs to be a container that does not encapsulate or it should make it's data private. Another example is an implementation flaw. When you create a singleton you want to ensure there is only one such object. If it is possible to create another instance then there is a flaw.

So multiple singleton objects and protected data members are examples of my mouse eating, lady bug painted, giant beetle. These can be considered software insects not because your customer cares about protected vs private or multiple singletons. These are software insects because someone tending your code (maybe even you) could step on them and create a big gooey mess.

How might these software insects be useful? It is useful to use each of these 'flaws' as a seam to test your code. A seam is a place where you can highjack functionality without changing the callsite you want to test. Substituting a derived class during testing is a very useful technique. In legacy code it can be a good practice to move private data to protected simply to allow the derived testing class the control it needs to do it's job. You then need to use engineering discipline rather than the compiler to ensure that you maintain your invariants. This is a techinique where you are trading compiler checked goodness for a possibly greater goodness ... deep targeted testing.

Often a singleton is used when you are enforcing a direct mapping to something physical (such an external input device). Imagine you are writing a software program to guess a person's birthdate by their weight on a scale. Do you want to test it by automating the placement of actual weight on a scale? Or by making a fake version of your singleton scale class and instantiating it?

There are alternative designs that avoid the need for a scary yet helpful software insect to provide testability. However, if you live in a code base that was not designed for testing, think about how these software insects could be your friend, as you travel toward those better designs.

Random Repros

SteveJS — Tue, 04 Oct 2005 04:08:00 GMT

Adi Oltean continues a great series of blogs about supportability, with this one about Random Repros. Stop reading this. Go read that. And reply in his comments, if you have any ideas nearly as good as his.

There are a couple of reason tough bugs are hard. The most common reason is the repro is too elusive. If you've ever dismissed a bug as 'No repro', think about the fact that someone did repro the problem at one point. Are you resolving 'No repro' because you think it doesn't exist now? Do you think the bug report was a mistake? Or are you saying 'No repro' because you cannot make progress without a repro? Next time you resolve 'No repro' make sure you are clear why. Then ask yourself: If there really is a bug here what could help track down a consistent repro?

I'm not claiming that chasing every red herring is a worthwhile exercise. Testing, and development are human processes and sometimes errors occur. Don't suspend good judgement. However, as a developer, it is better to be clear that you think a bug is a mistake then to whimp out with an unclarified 'No repro'. As a tester, if you get a resolution of 'No repro' it is worthwhile to ask the developer if they think the bug was a mistake, already fixed, or simply elusive. If the bug is simply hiding effectively, then it is everyone's job to help flush it out.