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
