mirror of
https://github.com/yuzu-emu/breakpad.git
synced 2024-10-19 00:18:19 +02:00
Update links
code.google.com is obsolete. Fix all broken markdown links while at it. Change-Id: I6a337bf4b84eacd5f5c749a4ee61331553279009 Reviewed-on: https://chromium-review.googlesource.com/411800 Reviewed-by: Mike Frysinger <vapier@chromium.org>
This commit is contained in:
Orgad Shaneh
Mike Frysinger
parent
8e2448bceb
commit
11d7510c08
@ -69,8 +69,8 @@ amount of work from a crashed process.
|
||||
|
||||
The mechanisms for installing an exception handler vary between operating
|
||||
systems. On Windows, it’s a relatively simple matter of making one call to
|
||||
register a [top-level exception filter]
|
||||
(http://msdn.microsoft.com/library/en-us/debug/base/setunhandledexceptionfilter.asp)
|
||||
register a [top-level exception
|
||||
filter](http://msdn.microsoft.com/library/en-us/debug/base/setunhandledexceptionfilter.asp)
|
||||
callback function. On most Unix-like systems such as Linux, processes are
|
||||
informed of exceptions by the delivery of a signal, so an exception handler
|
||||
takes the form of a signal handler. The native mechanism to catch exceptions on
|
||||
@ -178,9 +178,8 @@ didn’t actually handle an exception. This function may be useful for developer
|
||||
who want to test their applications with Breakpad enabled but still retain the
|
||||
ability to use traditional debugging techniques. It also allows a
|
||||
Breakpad-enabled application to coexist with a platform’s native crash reporting
|
||||
system, such as Mac OS X’ [CrashReporter]
|
||||
(http://developer.apple.com/technotes/tn2004/tn2123.html) and [Windows Error
|
||||
Reporting](http://msdn.microsoft.com/isv/resources/wer/).
|
||||
system, such as Mac OS X’ [CrashReporter](http://developer.apple.com/technotes/tn2004/tn2123.html)
|
||||
and [Windows Error Reporting](http://msdn.microsoft.com/isv/resources/wer/).
|
||||
|
||||
Typically, when Breakpad handles an exception fully and no debuggers are
|
||||
involved, the crashed process will terminate.
|
||||
|
||||
@ -9,8 +9,7 @@ minidumps on request for programs that have not crashed.
|
||||
Breakpad is currently used by Google Chrome, Firefox, Google Picasa, Camino,
|
||||
Google Earth, and other projects.
|
||||
|
||||
![http://google-breakpad.googlecode.com/svn/wiki/breakpad.png]
|
||||
(http://google-breakpad.googlecode.com/svn/wiki/breakpad.png)
|
||||
|
||||
|
||||
Breakpad has three main components:
|
||||
|
||||
@ -90,7 +89,7 @@ known as "out-of-process" exception handling.
|
||||
## Breakpad Code Overview
|
||||
|
||||
All the client-side code is found by visiting the Google Project at
|
||||
http://code.google.com/p/google-breakpad. The following directory structure is
|
||||
https://chromium.googlesource.com/breakpad/breakpad. The following directory structure is
|
||||
present in the `src` directory:
|
||||
|
||||
* `processor` Contains minidump-processing code that is used on the server
|
||||
@ -101,14 +100,9 @@ present in the `src` directory:
|
||||
|
||||
(Among other directories)
|
||||
|
||||
* <a
|
||||
href='http://code.google.com/p/google-breakpad/wiki/WindowsClientIntegration'>Windows
|
||||
Integration Guide</a>
|
||||
* <a
|
||||
href='http://code.google.com/p/google-breakpad/wiki/MacBreakpadStarterGuide'>Mac
|
||||
Integration Guide</a>
|
||||
* <a href='http://code.google.com/p/google-breakpad/wiki/LinuxStarterGuide'>
|
||||
Linux Integration Guide</a>
|
||||
* [Windows Integration Guide](windows_client_integration.md)
|
||||
* [Mac Integration Guide](mac_breakpad_starter_guide.md)
|
||||
* [Linux Integration Guide](linux_starter_guide.md)
|
||||
|
||||
## Build process specifics(symbol generation)
|
||||
|
||||
|
||||
@ -75,10 +75,8 @@
|
||||
|
||||
## More Information
|
||||
|
||||
* Project home: http://code.google.com/p/google-breakpad/
|
||||
* Project home: https://chromium.googlesource.com/breakpad/breakpad
|
||||
* Mailing lists
|
||||
* [google-breakpad-dev@googlegroups.com]
|
||||
(http://groups.google.com/group/google-breakpad-dev/)
|
||||
* [google-breakpad-discuss@googlegroups.com]
|
||||
(http://groups.google.com/group/google-breakpad-discuss/)
|
||||
* [google-breakpad-dev@googlegroups.com](http://groups.google.com/group/google-breakpad-dev/)
|
||||
* [google-breakpad-discuss@googlegroups.com](http://groups.google.com/group/google-breakpad-discuss/)
|
||||
* Ask me (irc.mozilla.org: mento)
|
||||
|
||||
@ -13,8 +13,9 @@ The Breakpad processor is intended to sit at the core of a comprehensive
|
||||
crash-reporting system that does not require debugging information to be
|
||||
provided to those running applications being monitored. Some existing
|
||||
crash-reporting systems, such as [GNOME](http://www.gnome.org/)’s Bug-Buddy and
|
||||
[Apple](http://www.apple.com/)’s [CrashReporter]
|
||||
(http://developer.apple.com/technotes/tn2004/tn2123.html), require symbolic
|
||||
[Apple](http://www.apple.com/)’s
|
||||
[CrashReporter](http://developer.apple.com/technotes/tn2004/tn2123.html),
|
||||
require symbolic
|
||||
information to be present on the end user’s computer; in the case of
|
||||
CrashReporter, the reports are transmitted only to Apple, not to third-party
|
||||
developers. Other systems, such as [Microsoft](http://www.microsoft.com/)’s
|
||||
@ -81,13 +82,12 @@ set to produce dumps at any time a developer deems appropriate. The Breakpad
|
||||
processor can handle dumps in the minidump format, either generated by an
|
||||
[Breakpad client “handler”](client_design.md) implementation, or by another
|
||||
implementation that produces dumps in this format. The
|
||||
[DbgHelp.dll!MiniDumpWriteDump]
|
||||
(http://msdn2.microsoft.com/en-us/library/ms680360.aspx) function on Windows
|
||||
[DbgHelp.dll!MiniDumpWriteDump](http://msdn2.microsoft.com/en-us/library/ms680360.aspx)
|
||||
function on Windows
|
||||
produces dumps in this format, and is the basis for the Breakpad handler
|
||||
implementation on that platform.
|
||||
|
||||
The [minidump format]
|
||||
(http://msdn.microsoft.com/en-us/library/ms679293%28VS.85%29.aspx) is
|
||||
The [minidump format](http://msdn.microsoft.com/en-us/library/ms679293%28VS.85%29.aspx) is
|
||||
essentially a simple container format, organized as a series of streams. Each
|
||||
stream contains some type of data relevant to the crash. A typical “normal”
|
||||
minidump contains streams for the thread list, the module list, the CPU context
|
||||
@ -155,11 +155,12 @@ storage needs.
|
||||
|
||||
Breakpad’s symbol file format is text-based, and was defined to be fairly
|
||||
human-readable and to encompass the needs of multiple platforms. The Breakpad
|
||||
processor itself does not operate directly with native symbol formats ([DWARF]
|
||||
(http://dwarf.freestandards.org/) and [STABS]
|
||||
(http://sourceware.org/gdb/current/onlinedocs/stabs.html) on most Unix-like
|
||||
systems, [.pdb files]
|
||||
(http://msdn2.microsoft.com/en-us/library/yd4f8bd1(VS.80).aspx) on Windows),
|
||||
processor itself does not operate directly with native symbol formats
|
||||
([DWARF](http://dwarf.freestandards.org/) and
|
||||
[STABS](http://sourceware.org/gdb/current/onlinedocs/stabs.html)
|
||||
on most Unix-like systems,
|
||||
[.pdb files](http://msdn2.microsoft.com/en-us/library/yd4f8bd1(VS.80).aspx)
|
||||
on Windows),
|
||||
because of the complications in accessing potentially complex symbol formats
|
||||
with slight variations between platforms, stored within different types of
|
||||
binary formats. In the case of `.pdb` files, the debugging format is not even
|
||||
|
||||
@ -8,16 +8,12 @@ traces from the information contained within a minidump file.
|
||||
## Starting the Process
|
||||
|
||||
Typically the stack walking process is initiated by instantiating the
|
||||
[MinidumpProcessor]
|
||||
(http://code.google.com/p/google-breakpad/source/browse/trunk/src/processor/minidump_processor.cc)
|
||||
class and calling the [MinidumpProcessor::Process]
|
||||
(http://code.google.com/p/google-breakpad/source/browse/trunk/src/processor/minidump_processor.cc#61)
|
||||
[MinidumpProcessor](../src/processor/minidump_processor.cc)
|
||||
class and calling the [MinidumpProcessor::Process](../src/processor/minidump_processor.cc#61)
|
||||
method, providing it a minidump file to process. To produce a useful stack
|
||||
trace, the MinidumpProcessor requires two other objects which are passed in its
|
||||
constructor: a [SymbolSupplier]
|
||||
(http://code.google.com/p/google-breakpad/source/browse/trunk/src/google_breakpad/processor/symbol_supplier.h)
|
||||
and a [SourceLineResolverInterface]
|
||||
(http://code.google.com/p/google-breakpad/source/browse/trunk/src/google_breakpad/processor/source_line_resolver_interface.h).
|
||||
constructor: a [SymbolSupplier](../src/google_breakpad/processor/symbol_supplier.h)
|
||||
and a [SourceLineResolverInterface](../src/google_breakpad/processor/source_line_resolver_interface.h).
|
||||
The SymbolSupplier object is responsible for locating and providing SymbolFiles
|
||||
that match modules from the minidump. The SourceLineResolverInterface is
|
||||
responsible for loading the symbol files and using the information contained
|
||||
@ -26,29 +22,26 @@ information on how to unwind from a stack frame to its caller. More detail will
|
||||
be provided on these interactions later.
|
||||
|
||||
A number of data streams are extracted from the minidump to begin stack walking:
|
||||
the list of threads from the process ([MinidumpThreadList]
|
||||
(http://code.google.com/p/google-breakpad/source/browse/trunk/src/google_breakpad/processor/minidump.h#335)),
|
||||
the list of modules loaded in the process ([MinidumpModuleList]
|
||||
(http://code.google.com/p/google-breakpad/source/browse/trunk/src/google_breakpad/processor/minidump.h#501)),
|
||||
the list of threads from the process
|
||||
([MinidumpThreadList](../src/google_breakpad/processor/minidump.h#335)),
|
||||
the list of modules loaded in the process
|
||||
([MinidumpModuleList](../src/google_breakpad/processor/minidump.h#501)),
|
||||
and information about the exception that caused the process to crash
|
||||
([MinidumpException]
|
||||
(http://code.google.com/p/google-breakpad/source/browse/trunk/src/google_breakpad/processor/minidump.h#615)).
|
||||
([MinidumpException](../src/google_breakpad/processor/minidump.h#615)).
|
||||
|
||||
## Enumerating Threads
|
||||
|
||||
For each thread in the thread list ([MinidumpThread]
|
||||
(http://code.google.com/p/google-breakpad/source/browse/trunk/src/google_breakpad/processor/minidump.h#299)),
|
||||
the thread memory containing the stack for the thread ([MinidumpMemoryRegion]
|
||||
(http://code.google.com/p/google-breakpad/source/browse/trunk/src/google_breakpad/processor/minidump.h#236))
|
||||
For each thread in the thread list
|
||||
([MinidumpThread](../src/google_breakpad/processor/minidump.h#299)),
|
||||
the thread memory containing the stack for the thread
|
||||
([MinidumpMemoryRegion](../src/google_breakpad/processor/minidump.h#236))
|
||||
and the CPU context representing the CPU state of the thread at the time the
|
||||
dump was written ([MinidumpContext]
|
||||
(http://code.google.com/p/google-breakpad/source/browse/trunk/src/google_breakpad/processor/minidump.h#171))
|
||||
dump was written ([MinidumpContext](../src/google_breakpad/processor/minidump.h#171))
|
||||
are extracted from the minidump. If the thread being processed is the thread
|
||||
that produced the exception then a CPU context is obtained from the
|
||||
MinidumpException object instead, which represents the CPU state of the thread
|
||||
at the point of the exception. A stack walker is then instantiated by calling
|
||||
the [Stackwalker::StackwalkerForCPU]
|
||||
(http://code.google.com/p/google-breakpad/source/browse/trunk/src/google_breakpad/processor/stackwalker.h#77)
|
||||
the [Stackwalker::StackwalkerForCPU](../src/google_breakpad/processor/stackwalker.h#77)
|
||||
method and passing it the CPU context, the thread memory, the module list, as
|
||||
well as the SymbolSupplier and SourceLineResolverInterface. This method selects
|
||||
the specific !Stackwalker subclass based on the CPU architecture of the provided
|
||||
@ -57,8 +50,7 @@ CPU context and returns an instance of that subclass.
|
||||
## Walking a thread's stack
|
||||
|
||||
Once a !Stackwalker instance has been obtained, the processor calls the
|
||||
[Stackwalker::Walk]
|
||||
(http://code.google.com/p/google-breakpad/source/browse/trunk/src/google_breakpad/processor/source_line_resolver_interface.h)
|
||||
[Stackwalker::Walk](../src/google_breakpad/processor/source_line_resolver_interface.h)
|
||||
method to obtain a list of frames representing the stack of this thread. The
|
||||
!Stackwalker starts by calling the GetContextFrame method which returns a
|
||||
StackFrame representing the top of the stack, with CPU state provided by the
|
||||
@ -69,28 +61,24 @@ for each frame in turn:
|
||||
|
||||
The address of the instruction pointer of the current frame is used to determine
|
||||
which module contains the current frame by calling the module list's
|
||||
[GetModuleForAddress]
|
||||
(http://code.google.com/p/google-breakpad/source/browse/trunk/src/google_breakpad/processor/code_modules.h#56)
|
||||
method.
|
||||
[GetModuleForAddress](../src/google_breakpad/processor/code_modules.h#56) method.
|
||||
|
||||
### Locating Symbols
|
||||
|
||||
If a module is located, the SymbolSupplier is asked to locate symbols
|
||||
corresponding to the module by calling its [GetCStringSymbolData]
|
||||
(http://code.google.com/p/google-breakpad/source/browse/trunk/src/google_breakpad/processor/symbol_supplier.h#87)
|
||||
corresponding to the module by calling its
|
||||
[GetCStringSymbolData](../src/google_breakpad/processor/symbol_supplier.h#87)
|
||||
method. Typically this is implemented by using the module's debug filename (the
|
||||
PDB filename for Windows dumps) and debug identifier (a GUID plus one extra
|
||||
digit) as a lookup key. The [SimpleSymbolSupplier]
|
||||
(http://code.google.com/p/google-breakpad/source/browse/trunk/src/processor/simple_symbol_supplier.cc)
|
||||
digit) as a lookup key. The [SimpleSymbolSupplier](../src/processor/simple_symbol_supplier.cc)
|
||||
class simply uses these as parts of a file path to locate a flat file on disk.
|
||||
|
||||
### Loading Symbols
|
||||
|
||||
If a symbol file is located, the SourceLineResolverInterface is then asked to
|
||||
load the symbol file by calling its [LoadModuleUsingMemoryBuffer]
|
||||
(http://code.google.com/p/google-breakpad/source/browse/trunk/src/google_breakpad/processor/source_line_resolver_interface.h#71)
|
||||
method. The [BasicSourceLineResolver]
|
||||
(http://code.google.com/p/google-breakpad/source/browse/trunk/src/processor/basic_source_line_resolver.cc)
|
||||
load the symbol file by calling its
|
||||
[LoadModuleUsingMemoryBuffer](../src/google_breakpad/processor/source_line_resolver_interface.h#71)
|
||||
method. The [BasicSourceLineResolver](../src/processor/basic_source_line_resolver.cc)
|
||||
implementation parses the text-format [symbol file](symbol_files.md) into
|
||||
in-memory data structures to make lookups by address of function names, source
|
||||
line information, and unwind information easy.
|
||||
@ -98,8 +86,7 @@ line information, and unwind information easy.
|
||||
### Getting source line information
|
||||
|
||||
If a symbol file has been successfully loaded, the SourceLineResolverInterface's
|
||||
[FillSourceLineInfo]
|
||||
(http://code.google.com/p/google-breakpad/source/browse/trunk/src/google_breakpad/processor/source_line_resolver_interface.h#89)
|
||||
[FillSourceLineInfo](../src/google_breakpad/processor/source_line_resolver_interface.h#89)
|
||||
method is called to provide a function name and source line information for the
|
||||
current frame. This is done by subtracting the base address of the module
|
||||
containing the current frame from the instruction pointer of the current frame
|
||||
@ -119,17 +106,15 @@ nearest symbol that is less than the provided RVA.
|
||||
|
||||
### Finding the caller frame
|
||||
|
||||
To find the next frame in the stack, the !Stackwalker calls its [GetCallerFrame]
|
||||
(http://code.google.com/p/google-breakpad/source/browse/trunk/src/google_breakpad/processor/stackwalker.h#186)
|
||||
To find the next frame in the stack, the !Stackwalker calls its
|
||||
[GetCallerFrame](../src/google_breakpad/processor/stackwalker.h#186)
|
||||
method, passing in the current frame. Each !Stackwalker subclass implements
|
||||
GetCallerFrame differently, but there are common patterns.
|
||||
|
||||
Typically the first step is to query the SourceLineResolverInterface for the
|
||||
presence of detailed unwind information. This is done using its
|
||||
[FindWindowsFrameInfo]
|
||||
(http://code.google.com/p/google-breakpad/source/browse/trunk/src/google_breakpad/processor/source_line_resolver_interface.h#96)
|
||||
and [FindCFIFrameInfo]
|
||||
(http://code.google.com/p/google-breakpad/source/browse/trunk/src/google_breakpad/processor/source_line_resolver_interface.h#102)
|
||||
[FindWindowsFrameInfo](../src/google_breakpad/processor/source_line_resolver_interface.h#96)
|
||||
and [FindCFIFrameInfo](../src/google_breakpad/processor/source_line_resolver_interface.h#102)
|
||||
methods. These methods look for Windows unwind info extracted from a PDB file
|
||||
([STACK WIN](SymbolFiles#STACK_WIN_records.md) lines from the symbol file), or
|
||||
DWARF CFI extracted from a binary ([STACK CFI](SymbolFiles#STACK_CFI_records.md)
|
||||
@ -148,12 +133,11 @@ to produce the caller frame.
|
||||
|
||||
If no caller frame was found by any other method most !Stackwalker
|
||||
implementations resort to stack scanning by looking at each word on the stack
|
||||
down to a fixed depth (implemented in the [Stackwalker::ScanForReturnAddress]
|
||||
(http://code.google.com/p/google-breakpad/source/browse/trunk/src/google_breakpad/processor/stackwalker.h#131)
|
||||
down to a fixed depth (implemented in the
|
||||
[Stackwalker::ScanForReturnAddress](../src/google_breakpad/processor/stackwalker.h#131)
|
||||
method) and using a heuristic to attempt to find a reasonable return address
|
||||
(implemented in the [Stackwalker::InstructionAddressSeemsValid]
|
||||
(http://code.google.com/p/google-breakpad/source/browse/trunk/src/google_breakpad/processor/stackwalker.h#111)
|
||||
method).
|
||||
(implemented in the
|
||||
[Stackwalker::InstructionAddressSeemsValid](../src/google_breakpad/processor/stackwalker.h#111) method).
|
||||
|
||||
If no caller frame is found or the caller frame seems invalid, stack walking
|
||||
stops. If a caller frame was found then these steps repeat using the new frame
|
||||
|
||||
@ -197,10 +197,10 @@ All fields of a `STACK WIN` record, except for the last, are hexadecimal
|
||||
numbers.
|
||||
|
||||
The _type_ field indicates what sort of stack frame data this record holds. Its
|
||||
value should be one of the values of the [StackFrameTypeEnum]
|
||||
(http://msdn.microsoft.com/en-us/library/bc5207xw%28VS.100%29.aspx) type in
|
||||
Microsoft's [Debug Interface Access (DIA)]
|
||||
(http://msdn.microsoft.com/en-us/library/x93ctkx8%28VS.100%29.aspx) API.
|
||||
value should be one of the values of the
|
||||
[StackFrameTypeEnum](http://msdn.microsoft.com/en-us/library/bc5207xw%28VS.100%29.aspx)
|
||||
type in Microsoft's
|
||||
[Debug Interface Access (DIA)](http://msdn.microsoft.com/en-us/library/x93ctkx8%28VS.100%29.aspx) API.
|
||||
Breakpad uses only records of type 4 (`FrameTypeFrameData`) and 0
|
||||
(`FrameTypeFPO`); it ignores others. These types differ only in whether the last
|
||||
field is an _allocates\_base\_pointer_ flag (`FrameTypeFPO`) or a program string
|
||||
@ -274,8 +274,7 @@ follows:
|
||||
* If the _has\_program\_string_ field of a `STACK WIN` record is not zero,
|
||||
then the record's final field is a string containing a program to be
|
||||
interpreted to recover the caller's frame. The comments in the
|
||||
[postfix\_evaluator.h]
|
||||
(http://code.google.com/p/google-breakpad/source/browse/trunk/src/processor/postfix_evaluator.h#40)
|
||||
[postfix\_evaluator.h](../src/processor/postfix_evaluator.h#40)
|
||||
header file explain the language in which the program is written. You should
|
||||
place the following variables in the dictionary before interpreting the
|
||||
program:
|
||||
|
||||
@ -126,7 +126,7 @@ extern "C" {
|
||||
mach_msg_header_t* reply);
|
||||
|
||||
// This symbol must be visible to dlsym() - see
|
||||
// http://code.google.com/p/google-breakpad/issues/detail?id=345 for details.
|
||||
// https://bugs.chromium.org/p/google-breakpad/issues/detail?id=345 for details.
|
||||
kern_return_t catch_exception_raise(mach_port_t target_port,
|
||||
mach_port_t failed_thread,
|
||||
mach_port_t task,
|
||||
@ -464,7 +464,7 @@ kern_return_t ForwardException(mach_port_t task, mach_port_t failed_thread,
|
||||
|
||||
kern_return_t result;
|
||||
// TODO: Handle the case where |target_behavior| has MACH_EXCEPTION_CODES
|
||||
// set. https://code.google.com/p/google-breakpad/issues/detail?id=551
|
||||
// set. https://bugs.chromium.org/p/google-breakpad/issues/detail?id=551
|
||||
switch (target_behavior) {
|
||||
case EXCEPTION_DEFAULT:
|
||||
result = exception_raise(target_port, failed_thread, task, exception,
|
||||
|
||||
@ -202,7 +202,7 @@ bool CrashGenerator::CreateChildCrash(
|
||||
// On Android the signal sometimes doesn't seem to get sent even though
|
||||
// tkill returns '0'. Retry a couple of times if the signal doesn't get
|
||||
// through on the first go:
|
||||
// https://code.google.com/p/google-breakpad/issues/detail?id=579
|
||||
// https://bugs.chromium.org/p/google-breakpad/issues/detail?id=579
|
||||
#if defined(__ANDROID__)
|
||||
const int kRetries = 60;
|
||||
const unsigned int kSleepTimeInSeconds = 1;
|
||||
|
||||
@ -117,7 +117,7 @@
|
||||
// developer level errors. This implementation simply macros to NSLog/NSAssert.
|
||||
// It is not intended to be a general logging/reporting system.
|
||||
//
|
||||
// Please see http://code.google.com/p/google-toolbox-for-mac/wiki/DevLogNAssert
|
||||
// Please see https://github.com/google/google-toolbox-for-mac/wiki/DevLogNAssert
|
||||
// for a little more background on the usage of these macros.
|
||||
//
|
||||
// _GTMDevLog log some error/problem in debug builds
|
||||
|
||||
@ -74,7 +74,7 @@ using std::vector;
|
||||
// Returns true iff |context_size| matches exactly one of the sizes of the
|
||||
// various MDRawContext* types.
|
||||
// TODO(blundell): This function can be removed once
|
||||
// http://code.google.com/p/google-breakpad/issues/detail?id=550 is fixed.
|
||||
// https://bugs.chromium.org/p/google-breakpad/issues/detail?id=550 is fixed.
|
||||
static bool IsContextSizeUnique(uint32_t context_size) {
|
||||
int num_matching_contexts = 0;
|
||||
if (context_size == sizeof(MDRawContextX86))
|
||||
@ -473,7 +473,7 @@ bool MinidumpContext::Read(uint32_t expected_size) {
|
||||
|
||||
if (cpu_type != MD_CONTEXT_AMD64) {
|
||||
// TODO: Fall through to switch below.
|
||||
// http://code.google.com/p/google-breakpad/issues/detail?id=550
|
||||
// https://bugs.chromium.org/p/google-breakpad/issues/detail?id=550
|
||||
BPLOG(ERROR) << "MinidumpContext not actually amd64 context";
|
||||
return false;
|
||||
}
|
||||
@ -575,7 +575,7 @@ bool MinidumpContext::Read(uint32_t expected_size) {
|
||||
|
||||
if (cpu_type != MD_CONTEXT_PPC64) {
|
||||
// TODO: Fall through to switch below.
|
||||
// http://code.google.com/p/google-breakpad/issues/detail?id=550
|
||||
// https://bugs.chromium.org/p/google-breakpad/issues/detail?id=550
|
||||
BPLOG(ERROR) << "MinidumpContext not actually ppc64 context";
|
||||
return false;
|
||||
}
|
||||
@ -672,7 +672,7 @@ bool MinidumpContext::Read(uint32_t expected_size) {
|
||||
|
||||
if (cpu_type != MD_CONTEXT_ARM64) {
|
||||
// TODO: Fall through to switch below.
|
||||
// http://code.google.com/p/google-breakpad/issues/detail?id=550
|
||||
// https://bugs.chromium.org/p/google-breakpad/issues/detail?id=550
|
||||
BPLOG(ERROR) << "MinidumpContext not actually arm64 context";
|
||||
return false;
|
||||
}
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
If you wish to use these protobufs, you must generate their source files
|
||||
using protoc from the protobuf project (http://code.google.com/p/protobuf/).
|
||||
using protoc from the protobuf project (https://github.com/google/protobuf).
|
||||
|
||||
-----
|
||||
Troubleshooting for Protobuf:
|
||||
|
||||
@ -514,7 +514,7 @@ bool IsBoolFlag(bool from);
|
||||
// great together!
|
||||
// The weird 'using' + 'extern' inside the fLS namespace is to work around
|
||||
// an unknown compiler bug/issue with the gcc 4.2.1 on SUSE 10. See
|
||||
// http://code.google.com/p/google-gflags/issues/detail?id=20
|
||||
// https://github.com/gflags/gflags/issues/31
|
||||
#define DEFINE_string(name, val, txt) \
|
||||
namespace fLS { \
|
||||
static union { void* align; char s[sizeof(std::string)]; } s_##name[2]; \
|
||||
|
||||
Loading…
Reference in New Issue
Block a user