The current stack output is one line byte string which is not easy for
humans to parse. Extend the print mode to support a hexdump-like view
and switch to that by default. Now we get something like:
Stack
00000000 20 67 7b 53 94 7f 00 00 01 00 00 00 00 00 00 00 | g{S...........|
00000010 00 70 c4 44 9a 25 00 00 08 65 7a 53 94 7f 00 00 |.p.D.%...ezS...|
BUG=chromium:598947
Change-Id: I868e1cf4faa435a14c5f1c35f94a5db4a49b6a6d
Reviewed-on: https://chromium-review.googlesource.com/404008
Reviewed-by: Mark Mentovai <mark@chromium.org>
The base class here declares Read as virtual, so make sure it's
marked as override in the derived classes. This fixes some build
errors with clang.
src/google_breakpad/processor/minidump.h:853:8: error:
'Read' overrides a member function but is not marked 'override'
[-Werror,-Winconsistent-missing-override]
bool Read(uint32_t expected_size_);
^
src/google_breakpad/processor/minidump.h:153:16: note:
overridden virtual function is here
virtual bool Read(uint32_t expected_size) = 0;
^
Change-Id: Ie4e5fec097b7f37739433a9deb39e7ed60471461
Reviewed-on: https://chromium-review.googlesource.com/444385
Reviewed-by: Tobias Sargeant <tobiasjs@chromium.org>
This CL hits lots of source files because:
1. An update to the CodeModule virtual class. I added an is_loaded
method to specify whether the module is loaded. There were several
mocks/test classes that needed to be updated with an implementation.
An alternative to this route would be to modify
MinidumpUnloadedModule::code_file to prepend "Unloaded_" to the
module name.
2. Added an unloaded_modules parameter to
StackFrameSymbolizer::FillSourceLineInfo.
BUG=
Change-Id: Ic9c7f7c7b7e932a154a5d4ccf292c1527d8da09f
Reviewed-on: https://chromium-review.googlesource.com/430241
Reviewed-by: Ivan Penkov <ivanpe@chromium.org>
The implementations of Module/UnloadedModule and
ModuleList/UnloadedModuleList are very similar. They have been made
separate classes because they operate on different structs, complicating
factoring code into a base class and have sufficiently different
implementation that templates would not be suitable.
When unloaded modules have partially overlapping ranges, the module
shrink down feature is used to move the start of the higher range to the
end of the lower range. If two unloaded modules overlap identically, the
second module will not be added to the range map and the failure
ignored.
Places where MinidumpUnloadedModule differs from MinidumpModule:
code_identifier: the android/linux case is deleted since cv_records
never exist.
debug_file/debug_identifier/version: always return empty strings.
Read: an expected size is provided as opposed to MD_MODULE_SIZE. A
seek is used if there are extra, unused bytes.
Places where MinidumpUnloadedModuleList differs from
MinidumpModuleList:
Read: entry and header size is provided in the header in
addition to count. This changes the checks and handling of padding.
Failures from StoreRange are ignored.
GetMainModule: always returns NULL.
BUG=
Change-Id: I52e93d3ccc38483f50a6418fede8b506ec879aaa
Reviewed-on: https://chromium-review.googlesource.com/421566
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
This change is resolving an issue that was caused by the combination of:
- Android system libraries being relro packed in N+.
- Breakpad dealing with relro packed libraries in a hack way.
This is a fix for http://crbug/611824.
I also found an use-after-free issue (bug in Minidump::SeekToStreamType). I disallowed the MinidumpStreamInfo copy and assign constructors and the compiler detected another similar issue in Minidump::Print. Then I disabled the copy and assign constructors for most classes in minidump.h (just in case). There are a couple of classes where I couldn't disallow them (since assign is used). This will require a small refactor so I left it out of this CL.
R=mark@chromium.org
Review URL: https://codereview.chromium.org/2060663002 .
In Android, the mmap could be overlapped by /dev/ashmem, we adjusted
the range in https://breakpad.appspot.com/9744002/, but adjusted
range isn't written back to module, this caused the corresponding
module be dropped in BasicCodeModules copy constructor.
This also fix a lot of 'unable to store module' warnings
when dumping Android's minidump.
BUG=606972
R=mark@chromium.org, wfh@chromium.org
Review URL: https://codereview.chromium.org/1939333002 .
Patch from Tao Bai <michaelbai@chromium.org>.
If a MinidumpLinuxMapsList was created and destroyed without its Read method,
the program would have a segmentation fault because the destructor did not
check for a null maps_ field. Additional changes include additional
supplementary null checks, a potential memory leak fix, and some comment
removal.
Review URL: https://codereview.chromium.org/1271543002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1478 4c0a9323-5329-0410-9bdc-e9ce6186880e
when checking exploitability rating.
Linux minidumps do not support MD_MEMORY_INFO_LIST_STREAM, meaning the
processor cannot retrieve its memory mappings. However, it has its own
stream, MD_LINUX_MAPS, which contains memory mappings specific to Linux
(it contains the contents of /proc/self/maps). This CL allows the minidump
to gather information from the memory mappings for Linux minidumps.
In addition, exploitability rating for Linux dumps now use memory mappings
instead of checking the ELF headers of binaries. The basis for the change
is that checking the ELF headers requires the minidumps to store the memory
from the ELF headers, while the memory mapping data is already present,
meaning the size of a minidump will be unchanged.
As a result, of removing ELF header analysis, two unit tests have been removed.
Arguably, the cases that those unit tests check do not merit a high
exploitability rating and do not warrant a solid conclusion that was given
earlier.
R=ivanpe@chromium.org
Review URL: https://codereview.chromium.org/1251593007
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1476 4c0a9323-5329-0410-9bdc-e9ce6186880e
and updating minidump_stackwalk to show process uptime.
I tested this with a minidump from Chrome and I got a result that
is inline with what the Windows debugger is showing for that dump:
minidump_stackwalk output:
--------------------------
Process uptime: 601 seconds
WinDBG output:
--------------
Process Uptime: 0 days 0:10:01.000
I didn't update the machine readable output of minidump_stackwalk
on purpose in order to avoid breaking someone that uses it.
It can be added later to the machine output if needed.
R=mark@chromium.org
Review URL: https://breakpad.appspot.com/7754002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1406 4c0a9323-5329-0410-9bdc-e9ce6186880e
Tested with a minidump containing a version 3 structure to validate the string conversion routines. Interestingly enough the time_zone names does not appear to be abbreviation as the documentation was suggesting but full names, e.g. Eastern Standard Time:
MDRawMiscInfo
size_of_info = 232
flags1 = 0xf7
process_id = 0x54c4
process_create_time = 0x51a9323c
process_user_time = 0x1
process_kernel_time = 0x0
processor_max_mhz = 3100
processor_current_mhz = 1891
processor_mhz_limit = 3100
processor_max_idle_state = 0x1
processor_current_idle_state = 0x1
The new fileds follow:
process_integrity_level = 0x1000
process_execute_flags = 0x4d
protected_process = 0
time_zone_id = 2
time_zone.bias = 300
time_zone.standard_name = Eastern Standard Time
time_zone.daylight_name = Eastern Daylight Time
Review URL: https://breakpad.appspot.com/617002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1204 4c0a9323-5329-0410-9bdc-e9ce6186880e
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
We've gotten mixed advice from the lawyery types about whether this
matters. But it's easy enough to do.
a=jimblandy, r=nealsid
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@517 4c0a9323-5329-0410-9bdc-e9ce6186880e
In order to be able to treat any MemoryRegion as const, the accessor
functions need to be declared this-const, which means annotations on
all the subclasses, etc. etc.
Since MinidumpMemoryRegion fills its memory_ member on demand, that
member needs to be marked 'mutable', but this is exactly the sort of
situation the 'mutable' keyword was intended for, so that seems all
right.
a=jimblandy, r=nealsid
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@509 4c0a9323-5329-0410-9bdc-e9ce6186880e
