Share via

PDB always

  • Article

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.

Comments

  • Anonymous
    June 29, 2004
    if I compile in release mode, and then recompile in debug mode, and ship the release code to my customer, will the pdbs 'match' the release code I already shipped, if I decide to give him the pdbs at a later date?
  • Anonymous
    June 29, 2004
    Matthew: No. You can't mix-and-match with PDBs. You need to turn on creating the PDBs with the release build.
  • Anonymous
    June 29, 2004
    The comment has been removed
  • Anonymous
    June 29, 2004
    If there ain't no pdb nor else but the binary, you still can do some kernel debugging (also by using the WinAppCompatability Toolkit).

    That's sometimes quite confusing - still sometimes you get a hook, too.
    And if your app crashes AFTER it ended (I had that problem, C++ Runtime Error) it's the only way to get any idea.
  • Anonymous
    June 29, 2004
    I totally agree that PDBs should be generated for release builds. At the very least, the IDE should have an easy checkbox that says "Generate debug symbols for release builds", so you don't have to figure out symbols vs optimizations.
  • Anonymous
    June 30, 2004
    mikeb, good catch. We've always produced symbol files for our release builds to enable debugging of shipping bits. I never realized that this disabled optimizations in C#. Yikes!
  • Anonymous
    January 21, 2009
    PingBack from http://www.keyongtech.com/516825-performance-hit-with-debug-true