Why does the existence of a try/finally block stop the garbage collector from working?

Question

Just let me start off with a demonstration:

[TestMethod]
public void Test()
{
    var h = new WeakReference(new object());
    GC.Collect();
    Assert.IsNull(h.Target);
}

This code works as expected. After garbage collection is over, the reference in h is nullified. Now, here's the twist:

[TestMethod]
public void Test()
{
    var h = new WeakReference(new object());
    GC.Collect();
    try { }      // I just add an empty
    finally { }  // try/finally block
    Assert.IsNull(h.Target); // FAIL!
}

I add an empty try/finally block to the test after the GC.Collect() line and lo, the weakly referenced object is not collected! If the empty try/finally block is added before the GC.Collect() line, the test passes though.

What gives? Can anyone explain how in exactitude does try/finally blocks affect the lifetime of objects?

Note: all testing done in Debug. In Release both tests pass.

Note 2: To reproduce the app must be targeting either the .NET 4 or the .NET 4.5 runtime and it must be run as 32-bit (either target x86, or Any CPU with "Prefer 32-bit" option checked)

Non reproducible on an equivalent console program (VS 2010, both debug and release) — xanatos, Sep 05 '13 at 09:31
Could you check again please? I was able to reproduce it with both VS2010 and VS2012 in the equivalent console program, in Debug. — Stefan Dragnev, Sep 05 '13 at 09:53
Or on the speed of the machine... Try adding a GC.WaitForPendingFinalizers() after the GC.Collect(). — xanatos, Sep 05 '13 at 10:20
New info added - to reproduce must be targeting .NET 4+ and must run in 32-bit. It doesn't happen in 64-bit or in .NET 3.5 (any bitness). `WaitForPendingFinalizers` had no effect. — Stefan Dragnev, Sep 05 '13 at 10:37

score 3 · Accepted Answer · edited May 23 '17 at 10:31

When a debugger is attached, the jitter changes the lifetime of local variables. Explained in detail in this answer. Briefly, without a debugger the lifetime ends at the last use of the variable in the code, with a debugger it is extended to the end of the method to allow a Watch debugger expression to work.

While it looks like the new object() expression doesn't get stored in a variable in your code, there still is one after the jitter code generator is done with it. The object reference is stored on the stack frame at [ebp-44h], indistinguishable from the way a local variable would be used. The only way you can see that is by looking at the generated machine code, use Debug + Windows + Disassembly. This is otherwise entirely normal, these kind of redundant memory stores are eliminated by the jitter optimizer but it is not enabled in the Debug build.

Even though it is a temporary, this variable still needs to be reported to the GC as storing a reference. Necessary to prevent the object from getting collected when a GC occurs right between the object constructor call and the WeakReference constructor call. Possible if another thread in the program triggers a collection.

Without the try/finally blocks, the jitter can still discover that the stack frame slot stores a temporary and there isn't actually a need to extend its lifetime. So it stops reporting the lifetime of the temporary before the GC.Collect() call and the object gets collected.

But with the try/finally blocks, the jitter gives up trying to figure out if there is a possible usage of the stack frame slot in the try or finally blocks. And punts the problem by simply extending its lifetime to the end of the method, as would happen with a normal local variable.

This is all rather normal, you simply cannot make any reasonable assumptions about the way local variable references get treated in non-optimized code. This ought to also be a strong warning to anybody that actually uses a [TestMethod] that's run in a unit tester, never ever test the Debug build of code, only the Release build. It just won't behave the same as the way it works on the user's machine.

So it appears the x86 JIT is a bit of a weak-sauce. This issue doesn't happen with the x64 JIT or any .NET 2.0 JIT - it's apparently a JIT deficiency (or regression bug). — Stefan Dragnev, Sep 05 '13 at 10:56
The jitter has no obligation to generate optimized code when you intentionally disable the optimizer. Its only requirement is to generate correct and debuggable code. You can use connect.microsoft.com to report a regression but I foresee a quick "won't fix". This just doesn't need to be fixed. — Hans Passant, Sep 05 '13 at 11:26

score 0 · Answer 2 · edited May 23 '17 at 12:11

To make it easier to debug, in debug mode objects declared locally aren't disposed. While I wasn't able to reproduce your problem, with this code:

var x = new object();
var h = new WeakReference(x);
GC.Collect();
try { }      // I just add an empty
finally { }  // try/finally block
Console.WriteLine(h.Target != null);
Console.ReadKey();

I was able to reproduce the problem. If GC.Collect() was able to "collect" the new object(), if you put a breakpoint after the Console.ReadKey() you would be able to see an already disposed object (x).

Someone had asked something similar here: https://stackoverflow.com/a/755688/613130

A comment is interesting:

Because of optimizations in release mode, the reference scope is only valid till its last usage and not the entire block of code it is defined in.

clearly in debug mode it's the opposite, a reference scope is the whole scope in which it's defined.

Yes, I understand why your snippet reproduces the problem (lifetime of `x` extended to the end of scope for debug builds). However, I cannot consider your post an answer, because I was still able to reproduce the issue within a console app with the original snippet that doesn't have an `x` variable, so no scoping issues there. — Stefan Dragnev, Sep 05 '13 at 09:56

Why does the existence of a try/finally block stop the garbage collector from working?

2 Answers2