Eric, below are the responses from Eric van Beurden, who wrote the patch. I merely split it up and removed a bunch of traces for submission to WineHQ. The problem is that all of our changes were done initially in just a couple of huge commits during the initial import of dbghelp instead of nice, incremental changes. I split things up based mostly on a file by file basis, but I can further split this one as well
On Jan 18, 2008 3:14 PM, Eric Pouech eric.pouech@orange.fr wrote:
what's the rationale of optimized pdb ?
An optimized PDB file is generated with an optimized build of an app. Symbol addresses and ranges can overlap in these files. The existing implementation neither takes that into account when sorting the list nor when looking up symbols. This results in symbol lookups failing ~85-90% of the time.
the patch is already big enough not to mix code evolution with stuffing new trace:s all over the place
Understood.
Re: 7/10 - Fix file searching to search only listed directories instead of the whole HD:
you failed to set DebugFilePath to the desired value again the rest of the patch has nothing to do with the first part of the patch
Previously, the FindDebugInfoFile() function was using the function's return value string <DebugFilePath> as the me of the first file to open. This was an error since there is no requirement that this string be initialized to anything. However, you are correct in pointing out that the <DebugFilePath> variable did not get set in the event that the first attempt at finding the file succeeded. This fix will be submitted.
Re: 10/10 - Clamp minidump memory blocks to 928KB:
if that's really the case (and I'm even not sure we want to support this backward compatibility), a good fix would be to add several streams each up to 928k instead of clamping
After much more research and testing this turned out to be in error. The issue was not actually the size of the single stream, it was the ordering of the streams that windbg did not like. Windbg expects the six standard streams in the following order or else it will have trouble opening some minidumps: SystemInfoStream MiscInfoStream ExceptionStream ThreadListStream ModuleListStream MemoryListStream The stream table at the start of the file is sorted in numerical order by stream ID (as the current implementation has), but the actual stream data must appear in the above order after the file header. Our current fix for this is rather hacky and needs to be fixed properly and cleaned up before resubmitting. The proper fix would be to change the order that each stream is created, then to sort the stream table by stream ID before writing it to file.