Jason Green a écrit :
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.
hmm I still don't get how, in a generic way symbols could overlap the only think I could come up with if when static functions get automatically inlined by the compiler, but that's rather a different story (as I'd suspect the inlined function to be a single memory range within a container => and in that case returning the shortest matching symbol should be fine is there an existing exe/pdb file available for further testings
the patch is already big enough not to mix code evolution with stuffing new trace:s all over the place
Understood.
[snip]
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.
hmm still not sure it's the correct explanation... the 928k value is not that clear (and doesn't explain the impact of the order) I'd rather fear something like windbg mmaps the first meg of minidump upfront, and expects to get most the relevant information (the 5 listed streams, potentially header and data, in that mapping)... memory is likely to be used differently by another memory mapping, hence getting around the 1meg barrier (that's still needs to be further tested anyway)
A+