Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Errors-To: <wrowe@rowe-clan.net>
Message-Id: <5.2.0.9.2.20030306214613.03200008@pop3.rowe-clan.net>
Date: Thu, 06 Mar 2003 22:46:34 -0600
To: dev@apr.apache.org;;, dev@httpd.apache.org
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
Subject: I surrender (.pdb for releases, no .dbg)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

After spending many hours reviewing and actively using debug symbols
for real customer incidents, I have formed some different opinions and
wanted to share.

I'm convinced that with the Win32 debugging tools (free to download) 
available today, there is exactly one benefit to .dbg files - Dr. Watson
on WinNT can display backtraces.  It's already possible to display
those backtraces on the 98, ME, 2k and XP from .pdb files.  That small
benefit against the broken .pdb <-> binaries isn't worth that aggravation.

For me to collect the symbols from the public releases, into a symbols
store isn't possible today.  The very act of rebase'ing (when extracting)
the .dbg files breaks the original association between each binary and
it's complete .pdb information file.

The .dbg files are very lightweight flavors of (with much less info than) 
the comprehensive .pdb files.  Anyone on WinNT can simply use WinDbg
to bring up a crash dump created by Dr. Watson.  At that point, it's trivial
to look at the stack backtrace (complete with arguments) which is much
richer than Dr. Watson provides by default.

Of course a typical user won't understand either Dr. Watson or WinDbg,
but would be happy to forward a user.dmp file.  The .dbg files add nothing
to what we get out of .pdb files in helping to triage such a report.

So at this point, I'm ready to back out the .dbg file creation logic, leaving
the .pdb logic for complete analysis of crash dumps of any given ASF build
of the Apache releases.  Unless anyone has any objection, I should get to
this later tomorrow afternoon.

Bill