Finalization Queue or F-Reachable Queue? SOSEX (Not So) New Commands

As Steve Johnson, the author of the awesome SOSEX debugging extension, pointed out in a comment on my last finalization post, as of SOSEX 4.0 you can use the !finq and !frq commands to inspect separately the finalization queue and the f-reachable queue.

As a reminder, objects on the finalization queue are objects that are eligible for finalization but are still referenced by the application. These are objects for which finalizers will run at some point, but the GC has not passed them over to the finalizer thread’s control. Objects on the f-reachable queue, on the other hand, are in the finalizer thread’s hands—they are queued up and waiting for the finalizer thread to run their finalizers.

Using the same example from the previous post, we can inspect the finalization queue with !finq and discover that there are only a few objects on the finalization queue:

0:003> !finq -stat
Generation 0:
       Count      Total Size   Type
---------------------------------------------------------
         173            4152   MemoryLeak.Employee

173 objects, 4,152 bytes

Generation 1:
       Count      Total Size   Type
---------------------------------------------------------
           2              48   MemoryLeak.Employee

2 objects, 48 bytes

Generation 2:
       Count      Total Size   Type
---------------------------------------------------------
           1             104   System.Threading.Thread

1 objects, 104 bytes

However, there seem to be plenty of objects on the f-reachable queue, and their number grows over time, pointing towards a particular type of memory leak:

0:003> !frq -stat
Freachable Queue:
       Count      Total Size   Type
---------------------------------------------------------
         463           11112   MemoryLeak.Employee

463 objects, 11,112 bytes

Of course, if you use the commands without the –stat switch they will print out the entire contents of the respective queue, enabling you to inspect the individual objects. For example:

0:003> !finq
Generation 0:
Address               Size   Type
-----------------------------------------------------
0000000002e130c0        24   MemoryLeak.Employee
0000000002e15818        24   MemoryLeak.Employee
0000000002e17f70        24   MemoryLeak.Employee
0000000002e1a6c8        24   MemoryLeak.Employee
0000000002e1ce20        24   MemoryLeak.Employee
0000000002e1f578        24   MemoryLeak.Employee
…output snipped for brevity…

Light Page Heap in Application Verifier

Page Heap is an extremely useful diagnostic option that you can enable for your Windows application using GFlags or Application Verifier. When Page Heap is enabled, each heap allocation is placed on the end of a page boundary, and the subsequent page is marked as PAGE_NOACCESS. Any buffer overruns are therefore immediately caught.

While Page Heap is very useful, its cost is often too high for use in production applications. Fortunately, there is a more lightweight option, called (appropriately) Light Page Heap, that results in a smaller overhead at the expense of catching memory errors at a later point.

To enable Page Heap and perform additional configuration, such as switching to Light Page Heap or specifying which DLLs or memory ranges should use the Page Heap settings, use Application Verifier. After selecting your executable and choosing the Basics | Heaps test, right-click Heaps and select Properties for a variety of additional options.

When Full Page Heap is enabled, a buffer overrun manifests itself immediately as an access violation:

(c44.6cc): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=00aa3b04 ebx=602b2435 ecx=00000043 edx=0811b4fc esi=08bbf000 edi=00000064
eip=602b2473 esp=0946fe34 ebp=0946fe3c iopl=0         nv up ei pl nz ac pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010216
MSVCR100!wcscpy_s+0x3d:
602b2473 66890c02        mov     word ptr [edx+eax],cx    ds:002b:08bbf000=????
0:001> k
ChildEBP RetAddr
0946fe3c 00aa1a1e MSVCR100!wcscpy_s+0x3d
0946fe54 00aa1730 BatteryMeter!CPUInformation::CPUInformation+0x2e
0946fe80 765183db BatteryMeter!TemperatureAndBatteryUpdaterThread+0x90
0946fe8c 77899a3f KERNEL32!BaseThreadInitThunk+0xe
0946fed0 77899a12 ntdll!__RtlUserThreadStart+0x72
0946fee8 00000000 ntdll!_RtlUserThreadStart+0x1b

With Light Page Heap, on the other hand, you catch the error only when the overrun buffer is freed – Application Verifier detects that a suffix pattern at the end of the heap block was corrupted:

=======================================
VERIFIER STOP 0000000F: pid 0x1658: Corrupted suffix pattern for heap block.

    06191000 : Heap handle used in the call.
    089F32B0 : Heap block involved in the operation.
    000011D0 : Size of the heap block.
    089F4480 : Corruption address.

=======================================
This verifier stop is not continuable. Process will be terminated
when you use the `go' debugger command.

=======================================

(1658.c08): Break instruction exception - code 80000003 (first chance)
eax=000001a1 ebx=00000000 ecx=059cd7e0 edx=08bef4c1 esi=62ceda28 edi=000001ff
eip=62ce3355 esp=08bef798 ebp=08bef99c iopl=0         nv up ei pl nz na po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000202
vrfcore!VerifierStopMessageEx+0x578:
62ce3355 cc              int     3
0:001> k
ChildEBP RetAddr
08bef99c 62ce7d85 vrfcore!VerifierStopMessageEx+0x578
08bef9c4 61bd9922 vrfcore!VfCoreRedirectedStopMessage+0x88
08befa28 61bd9d5a verifier!AVrfpDphReportCorruptedBlock+0x1c2
08befa84 61bda252 verifier!AVrfpDphCheckNormalHeapBlock+0x11a
08befaa4 61bd8be3 verifier!AVrfpDphNormalHeapFree+0x22
08befac8 7791c526 verifier!AVrfDebugPageHeapFree+0xe3
08befb14 778c6a61 ntdll!RtlDebugFreeHeap+0x2f
08befb98 7788dd8e ntdll!RtlpFreeHeap+0x74
08befbbc 62cea6df ntdll!RtlFreeHeap+0x206
08befbd4 602b016a vrfcore!VfCoreRtlFreeHeap+0x16
08befbe8 00aa1784 MSVCR100!free+0x1c
08befc18 765183db BatteryMeter!TemperatureAndBatteryUpdaterThread+0xe4
08befc24 77899a3f KERNEL32!BaseThreadInitThunk+0xe
08befc68 77899a12 ntdll!__RtlUserThreadStart+0x72
08befc80 00000000 ntdll!_RtlUserThreadStart+0x1b

When chasing heap corruptions in real production applications, combining Light Page Heap with the ability to configure Page Heap only for suspect modules makes it realistic to catch the memory corruption without completely sacrificing application performance.

New C++ Concurrency Static Analysis Warnings in Visual Studio 2012

Another cool feature in the Visual Studio 2012 C++ compiler is the revamped code analysis rule sets and brand new UI for configuring them. This is not just the simple /analyze switch we all know and love since Visual Studio 2005 anymore.

To get a general impression of the UI changes, open a C++ project’s properties and check out the Code Analysis node. You’ll be able to review the rule set that runs on your project and optionally enable/disable specific warnings. Check out some of these rules:

Specifically, I’d like to focus on the new concurrency analysis rules (in the C261nn range). These rules—like most C++ code analysis rules—rely on annotations placed in the source code that instruct the analysis engine what to look for. For example, you can place a _Guarded_by_(X) annotation on a variable to indicate that access to it should always be protected by a lock X.

Carefully placing these annotations all over your source code might seem like an excessive burden, but this is an investment that pays off greatly when you later introduce subtle bugs. Consider the following simple example of an Account class, whose balance field is protected by the critical section lock:

class Account {
private:
  CRITICAL_SECTION lock;
  _Guarded_by_(lock) double balance;
public:
  //…constructor and other methods omitted for brevity
  void withdraw(double amount) {
    EnterCriticalSection(&lock);
    balance –= amount;
    LeaveCriticalSection(&lock);
  }
};

Sounds easy. Now you have a new requirement, to make sure that the balance is not negative before withdrawing. You make the following careless change, and oops—there’s a race condition in your class!

The code analysis engine will detect this problem and report it immediately:

There are many other use cases for these concurrency warnings: mark a variable with _Interlocked_ and the compiler will make sure it’s always accessed with an interlocked operation; failure to release a lock in some code path will always be triggered:

…and there’s the holy grail of deadlock detection, too, if you incorporate lock leveling into your code with the _Create_lock_level_, _Lock_level_order_ and _Has_lock_level_ annotations. Here’s an example:

This is definitely a step in the right direction for automatic code analysis in C++. You should at least once try running all the rules on your existing code base—you might be surprised how many nasty bugs code analysis could unveil!