ivan.penkov@gmail.com d394434a93 This change is addressing a particularly nasty issue where the stackwalker
doesn't see the correct thread stack memory.  Instead, it loads garbage
(from offset 0 of the minidump file - well that's not garbage, but it is
not the stack memory region either) and attempts to walk it.  A typical
symptom of this issue is when you get a single stack frame after
processing - the context frame - for which you don't need stack memory.

This issue is caused by an invalid RVA in the memory descriptor stored
inside the MINIDUMP_THREAD structure for the thread.  Luckily, the
invalid RVA is 0, and the start_of_memory_region appears to be correct,
so this issue can be easily detected and the correct memory region can be
loaded using an RVA specified in the MinidumpMemoryList.

I couldn't find a reasonable description on MSDN regarding
MINIDUMP_MEMORY_DESCRIPTOR.MINIDUMP_LOCATION_DESCRIPTOR having RVA of 0
except maybe for full dumps where the 64-bit version of the structure
(MINIDUMP_MEMORY_DESCRIPTOR64) is used and it has no RVA at all.  It has
a 64-bit DataSize which if interpreted as the 32-bit structure will very
likely result in 0 for the RVA:
  http://msdn.microsoft.com/en-us/library/windows/desktop/ms680384(v=vs.85).aspx 

Anyways, the dump that I looked at was not a full dump so 0 for RVA is a
bit puzzling (at least easily detectable):
...
Microsoft (R) Windows Debugger Version 6.2.9200.20512 X86
Copyright (c) Microsoft Corporation. All rights reserved.
...
User Mini Dump File: Only registers, stack and portions of memory are available
...
MINIDUMP_HEADER:
Version         A793 (62F0)
NumberOfStreams 11
Flags           160
                0020 MiniDumpWithUnloadedModules
                0040 MiniDumpWithIndirectlyReferencedMemory
                0100 MiniDumpWithProcessThreadData
Review URL: https://breakpad.appspot.com/606002

git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1194 4c0a9323-5329-0410-9bdc-e9ce6186880e
2013-06-27 20:34:30 +00:00
2012-10-09 17:15:06 +00:00
2006-09-20 21:16:16 +00:00
2013-04-24 10:06:14 +00:00
2013-04-24 10:06:14 +00:00
2010-08-13 18:49:03 +00:00
2012-09-05 08:08:53 +00:00

Breakpad is a set of client and server components which implement a
crash-reporting system.


-----
Getting started in 32-bit mode (from trunk)
Configure: CXXFLAGS=-m32 CFLAGS=-m32 CPPFLAGS=-m32 ./configure
    Build: make
     Test: make check
  Install: make install

If you need to reconfigure your build be sure to run "make distclean" first.


-----
To request change review:
0. Get access to a read-write copy of source.
   Owners at http://code.google.com/p/google-breakpad/ are able to grant
   this access.

1. Check out a read-write copy of source using instructions at
   http://code.google.com/p/google-breakpad/source/checkout

2. Make changes. Build and test your changes.
   For core code like processor use methods above.
   For linux/mac/windows, there are test targets in each project file.

3. Download http://codereview.appspot.com/static/upload.py

4. Run upload.py from the 'src' directory:
   upload.py --server=breakpad.appspot.com

   You will be prompted for credential and a description.

5. At http://breakpad.appspot.com you'll find your issue listed; click on it,
   and select Publish+Mail, and enter in the code reviewer and CC
   google-breakpad-dev@googlegroups.com

6. When applying code review feedback, specify the '-i' option when running
   upload.py again and pass the issue number so it updates the existing issue,
   rather than creating a new one.
   Be sure to rerun upload.py from the same directory as you did for previous
   uploads to allow for proper diff calculations.
Description
No description provided
Readme 39 MiB
Languages
C++ 68.2%
Makefile 12.8%
C 5.1%
Shell 5%
Objective-C 3.6%
Other 5.3%