getting line numbers of offending code in debug vs release builds

Question

My understanding is that with crash dump of debug build you can get the line number of stack trace and this does not happen with release build. In order to try this, I created a very simple application that crashes.

class Program  
{  
    static void Main(string[] args)  
    {  
        Console.WriteLine("Press any key to continue");  
        Console.ReadKey();  
        TestMe(null);  
    }  


    static void TestMe(MyClass c)  
    {  
        Console.WriteLine(c.Field);  
    }  
}  

class MyClass  
{  
    public string Field { get; set; }  
}

I created one debug build and one release build. Ran both of these and catpured crash dump via ADPlus. Below are the stack traces for each build. As you can see I am getting the line number in both builds. Obviously difference is that in release build its not reporting call to TestMe method. Any ideas why? Do I need add symbol path to application pdb files in both cases

Debug build

0:000> !CLRStack  
OS Thread Id: 0x2398 (0)  
Child SP IP       Call Site  
001eee74 003400db ConsoleApplication1.Program.TestMe(ConsoleApplication1.MyClass)*** WARNING: Unable to verify checksum for ConsoleApplication1.exe  
 [c:\ConsoleApplication1\ConsoleApplication1\Program.cs @ 20]  
001eee84 003400a5 ConsoleApplication1.Program.Main(System.String[]) [c:\ConsoleApplication1\ConsoleApplication1\Program.cs @ 14]  
001ef0c8 6ccb21bb [GCFrame: 001ef0c8]

Release build

0:000> !CLRStack  
OS Thread Id: 0x2e40 (0)  
Child SP IP       Call Site  
003bf5f8 772af8c1 [GCFrame: 003bf5f8] Unknown  
003bf3b4 002b0098 ConsoleApplication1.Program.Main(System.String[])*** WARNING: Unable to verify checksum for ConsoleApplication1.exe  
 [c:\ConsoleApplication1\ConsoleApplication1\Program.cs @ 14]  
003bf5f8 6ccb21bb [GCFrame: 003bf5f8]

possible duplicate of [When is a method eligible to be inlined by the CLR?](http://stackoverflow.com/questions/4660004/when-is-a-method-eligible-to-be-inlined-by-the-clr) — Hans Passant, Jan 03 '12 at 18:55

score 2 · Accepted Answer · answered Jan 03 '12 at 18:49

2

In the release build, the JIT compiler is no doubt inlining the method call - that's why the line number is different.

answered Jan 03 '12 at 18:49

Jon Skeet

1,421,763
867
9,128
9,194

so Release builds also report the line numbers in stack traces? I thought it happen in debug builds only. – palm snow Jan 03 '12 at 18:54
@palmsnow: I believe there's *more* debug information in debug builds than release builds, and obviously you still need to have the pdb file available, but if it's giving you line numbers, then that's helpful :) (In many places where release builds are used, the PDBs *aren't* shipped, which may have led to the confusion.) – Jon Skeet Jan 03 '12 at 18:56
While you're probably right that the JIT compiler will inline the call, the topmost stack frame is at a completely different address so I doubt this has anything to do with the inlining. I reckon that the address points to SEH code. – Brian Rasmussen Jan 03 '12 at 19:06
@Jon, When you say debug build has more debug information, can you please provide few speicific examples ( or links) on what exactly can I get in debug build that I cannot get in release build? – palm snow Jan 03 '12 at 19:08
1

@palmsnow: Debug builds are not optimized as aggressively as release builds, so you will be able to find locals and parameters easily. Futhermore inlining calls make stack traces a bit more complicated to read for release builds. – Brian Rasmussen Jan 03 '12 at 19:11
@BrianRasmussen: That stack frame does, I'd expect the reason for the `TestMe` call to be missing to be due to inlining. It's easy to test though - the OP can just prevent the method from being inlined using `[MethodImpl(MethodImplOptions.NoInlining)]` – Jon Skeet Jan 03 '12 at 19:12
@palmsnow: There are fewer symbols (I believe) in the release builds - I wouldn't expect local variable names to be present, for example. Note that there are two different aspects to optimization: compile-time and JIT-time... running under a debugger often ends up with very different code to running directly. – Jon Skeet Jan 03 '12 at 19:14
@JonSkeet: Agree, the reason TestMe isn't listed is most likely due to inlining. I was just trying to explain the topmost entry. – Brian Rasmussen Jan 03 '12 at 19:15
@BrianRasmussen: Okay - I wasn't sure what you meant by "I doubt this has anything to do with the inlining" - I thought you were meaning the answer to the question itself. – Jon Skeet Jan 03 '12 at 19:17
Scott Hanselman wrote a nice article about the differences of Debug and Release builds regarding inlining here: http://www.hanselman.com/blog/ReleaseISNOTDebug64bitOptimizationsAndCMethodInliningInReleaseBuildCallStacks.aspx – GaussZ Jan 03 '12 at 20:11

getting line numbers of offending code in debug vs release builds

1 Answers1