PDB always

In my last post, I wrote:

 

“Debugging information (pdb).  Set with ‘csc /debug[+|-]’.  It doesn’t affect codegen, so it’s really not very interesting.”

 

In my opinion, this should always be on, and compilers shouldn’t have an option to suppress the generation of debug info.  My experience is with the Microsoft C# and C++ compilers, but I bet it applies to most compilers out there.

 

I was surprised to find that it’s a pretty controversial point of view.

 

Here’s my thinking:

 

There’s little disadvantage. 

 

Turning on generation of .pdb files doesn’t affect the generated code.  It’s orthogonal to the optimization flags. 

 

In VC++ 5.0, the FPO data was in the generated DLLs, but that was it.  In VC++6.0, even that data was moved into the PDB file, and only a ~100byte header entry that pointed to the .PDB file remained

 

I’ve talked to the C# compiler guys, and they say it’s about the same for C#.

 

I’ve heard the concern that the .PDB files might make the C# output look bloated by comparison to tools that don’t generate debug info by default.  Obviously not a fair comparison, but the fear is there anyway.  (Kinda like the practice in the U.S. of setting gas prices to be $X.XX and 9/10 cents, because the other guy is doing it, too.)

 

I’ve also heard the concern that users may not realize they’re generating PDBs, and will just copy the entire output directory when they deploy.  That could make web downloads slower (kinda bad). 

 

Another concern I’ve heard is that accidentally deployed PDBs might be a security risk – that the extra information exposed could give away information useful to a hacker.  It’s a valid concern, but not a critical one.  If your system isn’t secure with PDBs shared, then it’s just plain not secure. 

 

It’s really important

 

Did you know you can debug a release build?  Quite a few Visual Studio users don’t realize this fact!  Perhaps that’s because if there are no .PDBs generated (as is often the default for release builds), debugging just flops.  I think Microsoft has a responsibility to users here – to give you a better chance of realizing the debugging in release is possible, but turning on .PDB generation by default.

 

So….

 

You crank out a release build.  You deploy it to customers.  You get a support call about an issue that only repro’s on the customers machine.  You fire up the remote debugger.  Now, you’re going to need:

 

·         PDBs to debug with

·         Matching source

·         Your own copy of the exact same binaries

 

You can never produce PDBs for a build after the fact.  If you didn’t produce them when you did your final release build, it’s too late.  You could try to crank out a new build, but if the issue is a very subtle one, it might go away when you do that. 

 

If you have the ability to gather minidumps, then it’s even more critical – you must use the exact same matching PDBs & EXEs/DLLs.  Save them away and make backups!

 

Guidance

 

Take whatever machine you used to crank out the final release build, and put it in cold storage.  Don’t touch it.  If you need to crank out a .01 patch, or there’s ever confusion about exactly how the build was done, you have this machine waiting for you.

 

Turn on debug info for release build, always.

 

Save DLLs, PDBs, and a snapshot of sources for every release you make.