| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
BUG=756317
Change-Id: Id096372e5a0d1e7c70e95304b1f0c181f57d3882
Reviewed-on: https://chromium-review.googlesource.com/619126
Reviewed-by: Leonard Mosescu <mosescu@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The main motivation for this change is to handle very large stack
traces, normally the result of infinite recursion. This part is
actually fairly simple, relaxing a few self-imposed limits on how
many frames we can unwind and the max size for stack memory.
Relaxing these limits requires stricter and more consistent checks for
stack unwinding. There are a number of unwinding invariants that apply
to all the platforms:
1. stack pointer (and frame pointer) must be within the stack memory
(frame pointer, if preset, must point to the right frame too)
2. unwinding must monotonically increase SP
(except for the first frame unwind, this must be a strict increase)
3. Instruction pointer (return address) must point to a valid location
4. stack pointer (and frame pointer) must be appropriately aligned
This change is focused on 2), which is enough to guarantee that the
unwinding doesn't get stuck in an infinite loop.
1) is implicitly validated part of accessing the stack memory
(explicit checks might be nice though).
4) is ABI specific and while it may be valuable in catching suspicious
frames is not in the scope of this change.
3) is also an interesting check but thanks to just-in-time compilation
it's more complex than just calling
StackWalker::InstructionAddressSeemsValid()
and we don't want to drop parts of the callstack due to an overly
conservative check.
Bug: chromium:735989
Change-Id: I9aaba77c7fd028942d77c87d51b5e6f94e136ddd
Reviewed-on: https://chromium-review.googlesource.com/563771
Reviewed-by: Mark Mentovai <mark@chromium.org>
Reviewed-by: Ivan Penkov <ivanpe@chromium.org>
|
|
|
|
|
|
| |
Patch by Julian Seward <jseward@acm.org> R=ted at https://bugzilla.mozilla.org/show_bug.cgi?id=894264
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1206 4c0a9323-5329-0410-9bdc-e9ce6186880e
|
|
|
|
|
|
| |
R=mark at https://breakpad.appspot.com/535002/
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1121 4c0a9323-5329-0410-9bdc-e9ce6186880e
|
|
|
|
|
|
| |
r=mkrebs at https://breakpad.appspot.com/413002/
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1077 4c0a9323-5329-0410-9bdc-e9ce6186880e
|
|
|
|
|
|
|
| |
http://breakpad.appspot.com/459002/
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1068 4c0a9323-5329-0410-9bdc-e9ce6186880e
|
|
|
|
|
|
|
|
| |
respective parent classes so they can be used by other architecture implementations.
R=jimb at http://breakpad.appspot.com/205001/show
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@703 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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
'WindowsFrameInfo'.
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
|
|
|
|
|
|
|
|
|
| |
the processor. r=ted.mielczarek
http://groups.google.com/group/google-breakpad-dev/browse_thread/thread/cf56b767383a5d4b
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@172 4c0a9323-5329-0410-9bdc-e9ce6186880e
|
|
|
|
| |
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@122 4c0a9323-5329-0410-9bdc-e9ce6186880e
|
|
|
|
|
|
|
|
|
|
| |
Interface change: moved a few fields around in ProcessState; added new
arguments to Stackwalker and SymbolSupplier.
http://groups.google.com/group/airbag-dev/browse_thread/thread/17e4a48ec3ede932
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@101 4c0a9323-5329-0410-9bdc-e9ce6186880e
|
|
|
|
|
|
|
|
|
| |
to be used with MinidumpProcessor. The basic SourceLineResolver is now a
public interface (#89)
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@83 4c0a9323-5329-0410-9bdc-e9ce6186880e
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Introduces a standard API for dealing with modules. MinidumpModule
is now a concrete implementation of this API. Code may interact with
single modules using the CodeModule interface, and collections of
modules using its container, the CodeModules interface.
- CodeModule is used directly by SymbolSupplier implementations and
SourceLineResolver. Reliance on the specific implementation in
MinidumpModule has been eliminated.
- Module lists are now added to ProcessState objects. Module references
in each stack frame are now pointers to objects in these module lists.
- The sample minidump_stackwalk tool prints the module list after printing
all threads' stacks.
http://groups.google.com/group/airbag-dev/browse_frm/thread/a9c0550edde54cf8
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@74 4c0a9323-5329-0410-9bdc-e9ce6186880e
|
|
|
|
|
|
|
| |
http://groups.google.com/group/airbag-dev/browse_thread/thread/e01f177386e8794a
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@60 4c0a9323-5329-0410-9bdc-e9ce6186880e
|
|
|
|
|
|
|
| |
http://groups.google.com/group/airbag-dev/browse_thread/thread/bbcecab979fa82bc
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@49 4c0a9323-5329-0410-9bdc-e9ce6186880e
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
make Stackwalker::Walk create and return a CallStack instead of filling a
caller-supplied one (#54). r=bryner
Interface change: Stackwalker::Walk and MinidumpProcessor::Process now return
a new CallStack*.
http://groups.google.com/group/airbag-dev/browse_thread/thread/d2bad5d7c115c3fe
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@45 4c0a9323-5329-0410-9bdc-e9ce6186880e
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
r=bryner
- This change allows Airbag to properly walk win32 stacks produced by code
built with MSVC's frame pointer omission optimization (/Oy). This
optimization is enabled at /O1 and /O2.
- There too many interface and file format changes to list here.
http://groups.google.com/group/airbag-dev/browse_thread/thread/85ce85bfa8457ece
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@42 4c0a9323-5329-0410-9bdc-e9ce6186880e
|
|
- Implementation of PowerPC stackwalker. Tested using stackwalker_selftest
(#18).
- Hook up processor-side multi-CPU support in MinidumpProcessor and
minidump_stackwalk using the new Stackwalker::StackwalkerForCPU method.
http://groups.google.com/group/airbag-dev/browse_thread/thread/1c2fa7c5182a77a9
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@34 4c0a9323-5329-0410-9bdc-e9ce6186880e
|