In order to better distinguish Android and Linux minidumps, introduce
a new MD_OS_ANDROID definition, and modify related source code accordingly.
Also append the build-fingerprint to the minidump location descriptor.
This gives more information about the system image the device runs on.
Review URL: https://breakpad.appspot.com/405002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@981 4c0a9323-5329-0410-9bdc-e9ce6186880e
The new API allows to automatically upload repports to the crash server when the application restarts.
This change also:
- Correct a bug on the test for correct alignment of the abrt signal handler
- Add user friendly information on crashes for SIGABRT and NSException
Review URL: https://breakpad.appspot.com/361001
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@935 4c0a9323-5329-0410-9bdc-e9ce6186880e
The value of MD_CONTEXT_CPU_MASK in use assumes that only the lower 6 bits are used for flags, and the upper 26 bits are for the CPU type. However, as of Windows 7 SP1, the 7th bit is being used as a flag (per http://msdn.microsoft.com/en-us/library/hh134238%28v=vs.85%29.aspx and the Windows SDK headers). Adjusting MD_CONTEXT_CPU_MASK works, but unfortunately that masks off the existing value of MD_CONTEXT_ARM. This patch also changes the value of MD_CONTEXT_ARM and adjusts the minidump context reading machinery to gracefully handle minidumps with the old value.
R=mark at http://breakpad.appspot.com/302001
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@831 4c0a9323-5329-0410-9bdc-e9ce6186880e
This patch avoids unnecessary use of the <cfoo> headers in files that don't
actually use the identifiers they declare in the std:: namespace.
It also changes some files to better conform with the "Names and Order of
Includes" rules in the Google C++ Style Guide.
A=jimb R=mark
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@619 4c0a9323-5329-0410-9bdc-e9ce6186880e
This adds support for 'STACK CFI' records (DWARF CFI) to the AMD64
stack walker. This is necessary for the stack trace to include any
frames other than the youngest. Unit tests are included.
a=jimblandy, r=mmentovai
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@554 4c0a9323-5329-0410-9bdc-e9ce6186880e
This patch allows the Breakpad minidump processor to use data from
STACK CFI records to generate stack traces for the ARM processor.
In the symbol dumper, we need a table mapping DWARF CFI register
numbers to their names: STACK CFI records refer to registers by name.
In the processor, we expand StackwalkerARM::GetCallerFrame to see if
there are STACK CFI records covering the callee, and then use those to
recover the caller's register values.
There's no good reason the ARM walker couldn't use the SimpleCFIWalker
interface declared in cfi_frame_info.h. Unfortunately, that interface
assumes that one can map register names to member pointers of the raw
context type, while MDRawContextARM uses an array to hold the
registers' values: C++ pointer-to-member types can't refer to elements
of member arrays. So we have to write out SimpleCFIWalker::FindCallerRegisters
in StackwalkerARM::GetCallerFrame.
We define enum MDARMRegisterNumbers in minidump_cpu_arm.h, for
convenience in referring to certain ARM registers with dedicated
purposes, like the stack pointer and the PC.
We define validity flags in StackFrameARM for all the registers, since
CFI could theoretically recover any of them. In the same vein, we
expand minidump_stackwalk.cc to print the values of all valid
callee-saves registers in the context --- and use the proper names for
special-purpose registers.
We provide unit tests that give full code and branch coverage (with
minor exceptions). We add a testing interface to StackwalkerARM that
allows us to create context frames that lack some register values.
a=jimblandy, r=mmentovai
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@553 4c0a9323-5329-0410-9bdc-e9ce6186880e
Add a CFIFrameInfo class (named for symmetry with WindowsFrameInfo) to
represent the set of STACK CFI rules in effect at a given instruction,
and apply them to a set of register values. Provide a SimpleCFIWalker
class template, to allow the essential CFI code to be shared amongst
the different architectures.
Teach BasicSourceLineResolver to partially parse 'STACK CFI' records,
and produce the set of rules in effect at a given instruction on
demand, by combining the initial rule set and the appropriate rule
deltas in a CFIFrameInfo object.
Adapt StackwalkerX86 and StackFrameX86 to retrieve, store, and apply
CFI stack walking information.
Add validity flags for all the general-purpose registers to
StackFrameX86::ContextValidity.
a=jimblandy, r=mmentovai
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@549 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
At the moment, the StackWalker GetCallerFrame member function expects
a vector of WindowsFrameInfo structures, even though WindowsFrameInfo
is only used or useful on one one implementation (StackWalkerX86).
This patch changes StackWalker::GetCallerFrame to no longer expect the
WindowsFrameInfo structures, and changes all implementations to match.
In particular, StackWalkerX86 is changed to find the WindowsFrameInfo
data itself, and store a pointer to whatever it got in the StackFrame
object itself (which is really a StackFrameX86).
To allow GetCallerFrame implementations to look up stack walking data,
StackWalker::resolver_ needs to be made protected, not private.
a=jimblandy, r=mmentovai
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@491 4c0a9323-5329-0410-9bdc-e9ce6186880e
At the moment, FillSourceLineInfo returns Windows DIA-based stack
walking data. In addition to being ugly, this makes it difficult to
provide access to DWARF CFI-based stack walking data in a symmetrical
way.
This patch changes FillSourceLineInfo to do the single job its name
suggests, and adds a second member function to
SourceLineResolverInterface to retrieve Windows DIA stack walking
information. A sibling member function will provide access to DWARF
CFI stack walking data.
a=jimblandy, r=mmentovai
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@480 4c0a9323-5329-0410-9bdc-e9ce6186880e
Also, rename stack_frame_info.h to windows_frame_info.h.
If it seems odd to have functions like FillSourceLineInfo returning
Windows-specific data structures... well, it is! This patch just makes
it more obvious what's going on.
a=jimblandy, r=nealsid
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@471 4c0a9323-5329-0410-9bdc-e9ce6186880e
Modern GNU compilers warn about the #inclusion of <ext/hash_map>; that
container is deprecated, and code should use <tr1/unordered_map>
instead. However, to stay within the boundaries of C++ '98, it's
probably fine just to use plain old std::map.
Breakpad uses hash_map in three cases:
o The DWARF reader's SectionMap type maps object file section names to
data. This map is consulted once per section kind per DWARF
compilation unit; it is not performance-critical.
o The Mac dump_syms tool uses it to map machine architectures to
section maps in Universal binaries. It's hard to imagine there
ever being more than two entries in such a map.
o The processor's BasicSourceLineResolver uses a hash_map to map file
numbers to file names. This is the map that will probably have the
most entries, but it's only accessed once per frame, after we've
found the frame's line entry.
a=jimblandy
r=nealsid
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@393 4c0a9323-5329-0410-9bdc-e9ce6186880e
Written by Ginn Chen & Eagle.Lu@
R=nealsid (although I don't have a Solaris machine to build on, & these changes look localized to Sun-only builds)
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@314 4c0a9323-5329-0410-9bdc-e9ce6186880e
added in my last check-in for out-of-process dump generation. My last check-in broke the breakpad_client.sln
build for non debug builds since for the new project that I added (crash_generation.vcproj) to that solution,
I always only changed project properties for debug build. In fact, I didn't have the static-crt build configurations
for the new project either. Similar problems existed for the test application I added, windows/test/crash_generation_app).
This changelist contains changes to 2 solution files, 2 vcproj files and 1 .cc file. The fixes to .cc file are to avoid
warnings on variables used only in debug modes (in asserts) when building in release modes.
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@247 4c0a9323-5329-0410-9bdc-e9ce6186880e
