[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 at 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 (ericvb at transgaming.com)
> ---
>  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+

-- 
Eric Pouech
"The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)