When shipping software to a client, should debug symbols (.PDBs) be bundled with it? If the client finds a bug or vulnerability in the software, a full stack trace (and a memory dump if possible) would be very helpful for the vendor in reproducing it.
What are the pros/cons of giving clients debug symbols?
I personally like shipping software with all debug symbols. Sometimes a bug is only discovered in the client's environment.
However, in embedded environments where memory space is at a premium, I could see shipping without debugging symbols.
Clients don't need debug symbols to send crash dumps to vendors. Automated systems like Windows Error Reporting make it possible for clients to report crash dumps to vendors without even having to know what a crash dump is. And clients can always send you a kernel crash dump or a user mode minidump manually. You do need to keep the PDBs for your release builds around to do any post-mortem debugging.
Clients don't need debug symbols to report stack traces. If you don't enable frame pointer omission, a stack trace from a client's machine should be intact enough that you can decode it using the debug symbols or map files.
Usually .pdb files are not shipped to a client, but they should be kept for every released build in the developer company. Having these files, you can debug crush dumps from a client computers.
Important note: for Microsoft projects, it is impossible just to rebuild the same source code and use .pdb files from the build. .pdb files should be the same files that where created when release was built. Microsoft uses UIDs to match exe and .pdb files, if there is no match, debugging symbols are not loaded.
Shipping .pdb files to a client is harmless, but also useless, unless you can make debugging directly on client computer.