Re: [dbghelp 10/10] Clamp minidump memory blocks to 928KB

[Eric Pouech]

Jason Green a écrit :
> From 1127317807ec264541e2e03e6a633cefee8f697b Mon Sep 17 00:00:00 2001
> From: Jason Green <jason@jave01.(none)>
> Date: Thu, 17 Jan 2008 17:43:41 -0500
> Subject: [PATCH] Clamp minidump memory blocks to 928KB and improve TRACEs
> WinDbg can't read minidumps with memory blocks larger than this.
> From: Eric van Beurden ([e-mail])
>
> dlls/dbghelp/minidump.c |   35 +++++++++++++++++++++++++++++++++--
>  1 files changed, 33 insertions(+), 2 deletions(-)
>
> diff --git a/dlls/dbghelp/minidump.c b/dlls/dbghelp/minidump.c
> index 564d824..f113728 100644
> --- a/dlls/dbghelp/minidump.c
> +++ b/dlls/dbghelp/minidump.c
> @@ -32,6 +32,13 @@
>
> WINE_DEFAULT_DEBUG_CHANNEL(dbghelp);
> -
>
> +/* windbg isn't able to open minidump files if they contain a single memory block larger
> - than 928KB.  If a larger block is found, it simply reports that all following streams
> - could not be loaded.  This is as of WinDbg version 6.7.0005.1. */
>
> +#define MINIDUMP_MEMORY_BLOCK_MAX   (928 * 1024)
> -
> -
>
> struct dump_memory
>  {
>      ULONG                               base;
> @@ -640,8 +647,32 @@ static  void    dump_threads(struct dump_context* dc,
>              }
>              if (mdThd.Stack.Memory.DataSize && (flags_out & ThreadWriteStack))
>              {
> -
>            add_memory_block(dc, mdThd.Stack.StartOfMemoryRange,
> -
>                             mdThd.Stack.Memory.DataSize,
> -
>            ULONG   size;
> -
>            ULONG64 base;
> -
> -
> -
>            /* windbg only supports memory blocks up to 928KB in size.  Not sure where that
> -
>               specific amount comes from, but in testing it will completely fail to load
> -
>               all minidump streams that follow a memory block that is larger than 928KB.
> -
>               Because of this, we'll clamp all of the memory blocks that we add to the
> -
>               file. */                   
> -
>            if (mdThd.Stack.Memory.DataSize > MINIDUMP_MEMORY_BLOCK_MAX){
> -
>                size = MINIDUMP_MEMORY_BLOCK_MAX;
> -
> -
>                /* since this is the thread stack we'll want to save this block top-down
> -
>                   instead of just clamping the buffer size */
> -
>                base = mdThd.Stack.StartOfMemoryRange + (mdThd.Stack.Memory.DataSize - MINIDUMP_MEMORY_BLOCK_MAX);
> -
> -
>                TRACE("    clamping the stack block starting at 0x%08llx {oldSize = %u bytes, newSize = %u bytes, newBase = 0x%08llx}\n",
> -
>                        mdThd.Stack.StartOfMemoryRange, mdThd.Stack.Memory.DataSize, size, base);
> -
>            }
> -
> -
>            else{
> -
>                size = mdThd.Stack.Memory.DataSize;
> -
>                base = mdThd.Stack.StartOfMemoryRange;
> -
>            }
> -
> -
>            add_memory_block(dc, base, size,
>                             rva_base + sizeof(mdThdList.NumberOfThreads) +
>                                 mdThdList.NumberOfThreads * sizeof(mdThd) +
>                                 FIELD_OFFSET(MINIDUMP_THREAD, Stack.Memory.Rva));

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
A+