0.9.2-rc1 outstanding issues and win32 debug symbols

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

I see the following 'blocking' issues that need to be resolved before
we T&R 0.9.2 (and httpd adopts that revision for its next release .45)...

1. new env logic, courtesy Brane, still needs a bit of fleshing out on OS2
   and/or Netware?  Watching for confirmations from these two platforms.

2. new otherchild functions that work across implementations and designs.
   Patch waiting in my tree, but I need to vet a third time to assure I'm not 
   breaking something this time.  Certainly committed by noon tomorrow.

3. new diagnostics on Win32.  I've discovered that the two-step link+.pdb
   extraction, followed by rebase+.dbg extraction results in binaries that
   match (correctly) the .dbg symbols, but don't match the .pdb symbols
   because the timestamps of the binary jump in that second phase.  Needs
   some bandaid.

4. anything else I'm overlooking?

Good news is that the actual symbols (both .pdb and .dbg) work exactly
as intended, and it's a simple step to download and install the Debugging
Tools for Windows package from MS.  But I need to figure out how to get
those symbol files back in-sync with the binaries :-(  I expect more progress
tomorrow morning after I finish 2) above.  But it's lead me to pick up my
first bug (a known one actually, null entries in the apr_poll_t array on win32.)

Leads to a fun question; do we want (in the dist space) a simple way to
download the necessary .db_ and .pd_ files, as well as a .zip file or the
default distribution containing either .dbg or .pdb symbols?  I plan to create
one downloadable set for every binary released (apr family and httpd family.)
I'm thinking .dbg only to package with releases, because those files are 
1) lighter and 2) sufficent to read a backtrace from Dr. Watson.  I'm not 
considering .pdb files in any product installers/binary distributions, because 
the files are a waste of bandwidth for the average Joe.  In fact, I'm considering
using the -p option for rebase to strip down those .dbg symbols to the bare
bones required for Dr. Watson to backtrace, leaving all the meaty fun in .pdb
files alone.

The upshot of all of this is that we can either distribute a full .zip package
of those .pdb files for debugging-oriented folks to diagnose the occasional
user bug report with crash dump, or we can actually create a directory tree
where individual, compressed symbol files could be downloaded as-needed.
WinDbg's symbol server, which is installed locally or on a common server
for a developer team, can query an http server's tree for the required symbols
grabbing only the correctly dated files to match the binaries.  Note that the 
symbol server does cache the retrieved symbol files, so it benefits the 
developers that share a local server, and conserves ASF bandwidth, when 
the symbols are only pulled down occasionally by odd souls.

If configured correctly, it would grab a specific release of libapr.dll and
libapr.pdb out of a number of versions available in the tree, that match
the version the user was running according to the crash dump's records.
Crash dumps don't always grab all of the binaries if they aren't modified
from the original.  It would let us debug any released distribution of the
apr binaries, or httpd binaries, without keeping every last revision on our
local machines.

What say we?  Does this sound like something worth researching?  Allen,
Brane and fellow Win32 hackers, should I proceed to figure out how to
structure such a binaries and symbols resource after I finish the 
apr 0.9.2 and httpd 2.0.45 releases?  Of course I will set aside those files,
.zip the .pdb's for posterity, roll the .dbg files into the installer (optional 
feature, of course.)  We might also trash the /map extraction from our
link steps, seeing as .dbg and .pdb files contain everything we could ever
wish to have.

Finally, personal note, sorry it's taken so long for me to get this out the 
door ... the headcold I was hit with when I arrived back in Chicago really 
laid me flat for several days.  Not really better yet - but coping better now :-)

Bill

Re: 0.9.2-rc1 outstanding issues and win32 debug symbols

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

At 06:26 PM 2/19/2003, Allan Edwards wrote:
>>>I think having the .dbg symbols should be quite enough for a normal
>>>httpd installation, so I think fixing the timestamp problem isn't that
>>>important for 0.9.2/2.0.45. 
>
>As I said to Bill in another note, the timestamp difference does not
>seem to cause any problems for me. Using windbg to examine a user.dmp I can
>point it to the pdb files & source tree, and display the stack trace and
>variables with no problem.

Right, it's not the timestamp.  I suspect the internal stamp and '.dbg' notation
that my rebase is adding to the binaries (if you look from within depends.exe,
you will see Apache/APR binaries tagged as .dbg symbols, an artifact of
the rebase -x operation.)  I'm seeing the 'M' status code for mismatches
within WinDbg itself, using the list modules command.


>>One point I meant to make... can we make the .dbg simplified symbols
>>-p(rivate) such that they are even smaller?  With the full blown .pdb's
>>available to all who are interested, I don't see that as a shortcoming.
>+1
>
>>>If we can really do without the map files
>>>once the .dbg's are available, then I see nothing wrong with killing them.
>+1

Since Brane already spoke up, I'll do these two changes in the morning.
No, the pdb/dbg issue isn't holding up this release, we can all manage
just fine with a few stumbling blocks.  I'm the only one who held on to the
.map files, and while they me helped several times narrow down a segv, 
I never once got a request for the .map's corresponding to a release.

Bill

Re: 0.9.2-rc1 outstanding issues and win32 debug symbols

[Allan Edwards <ak...@us.ibm.com>]

>>I think having the .dbg symbols should be quite enough for a normal
>>httpd installation, so I think fixing the timestamp problem isn't that
>>important for 0.9.2/2.0.45. 

As I said to Bill in another note, the timestamp difference does not
seem to cause any problems for me. Using windbg to examine a user.dmp I can
point it to the pdb files & source tree, and display the stack trace and
variables with no problem.

> One point I meant to make... can we make the .dbg simplified symbols
> -p(rivate) such that they are even smaller?  With the full blown .pdb's
> available to all who are interested, I don't see that as a shortcoming.
+1

>>If we can really do without the map files
>>once the .dbg's are available, then I see nothing wrong with killing them.
+1

Allan

Re: 0.9.2-rc1 outstanding issues and win32 debug symbols

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

At 05:57 PM 2/18/2003, Branko Čibej wrote:
>William A. Rowe, Jr. wrote:
>
>>What say we?  Does this sound like something worth researching?  Allen,
>>Brane and fellow Win32 hackers, should I proceed to figure out how to
>>structure such a binaries and symbols resource after I finish the 
>>apr 0.9.2 and httpd 2.0.45 releases?  Of course I will set aside those files,
>>.zip the .pdb's for posterity, roll the .dbg files into the installer (optional 
>>feature, of course.)  We might also trash the /map extraction from our
>>link steps, seeing as .dbg and .pdb files contain everything we could ever
>>wish to have.
>
>I think having the .dbg symbols should be quite enough for a normal
>httpd installation, so I think fixing the timestamp problem isn't that
>important for 0.9.2/2.0.45. 

100% agreed here - as long as you don't keep .dbg and .pdb files together,
it *will* pickup the mismatched ,pdb files for debugging the application.
One point I meant to make... can we make the .dbg simplified symbols
-p(rivate) such that they are even smaller?  With the full blown .pdb's
available to all who are interested, I don't see that as a shortcoming.

>If we can really do without the map files
>once the .dbg's are available, then I see nothing wrong with killing them.

I believe so... if others agree I'll make all this so before the release.

Bill 

Re: 0.9.2-rc1 outstanding issues and win32 debug symbols

[Branko Čibej <br...@xbc.nu>]

William A. Rowe, Jr. wrote:

>What say we?  Does this sound like something worth researching?  Allen,
>Brane and fellow Win32 hackers, should I proceed to figure out how to
>structure such a binaries and symbols resource after I finish the 
>apr 0.9.2 and httpd 2.0.45 releases?  Of course I will set aside those files,
>.zip the .pdb's for posterity, roll the .dbg files into the installer (optional 
>feature, of course.)  We might also trash the /map extraction from our
>link steps, seeing as .dbg and .pdb files contain everything we could ever
>wish to have.
>  
>
I think having the .dbg symbols should be quite enough for a normal
httpd installation, so I think fixing the timestamp problem isn't that
important for 0.9.2/2.0.45. If we can really do without the map files
once the .dbg's are available, then I see nothing wrong with killing them.

-- 
Brane Čibej   <br...@xbc.nu>   http://www.xbc.nu/brane/