aboutsummaryrefslogtreecommitdiff
path: root/src/processor/stackwalker_amd64.cc
Commit message (Collapse)AuthorAgeFilesLines
* fix pointer style to match the style guideMike Frysinger2020-07-151-3/+3
| | | | | | | | | | We do this in a lot of places, but we're inconsistent. Normalize the code to the Google C++ style guide. Change-Id: Ic2aceab661ce8f6b993dda21b1cdf5d2198dcbbf Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2262932 Reviewed-by: Sterling Augustine <saugustine@google.com> Reviewed-by: Mark Mentovai <mark@chromium.org>
* Handle very large stack tracesLeonard Mosescu2017-07-121-25/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Sanity check frame pointer while stackwalkingJoshua Peraza2017-03-221-0/+6
| | | | | | | | BUG= Change-Id: Ib9b0fd5ba7f829f8be8cf856ab371c6540279ee5 Reviewed-on: https://chromium-review.googlesource.com/458526 Reviewed-by: Ivan Penkov <ivanpe@chromium.org>
* Make x86-64 frame pointer unwinding stricterTed Mielczarek2016-04-191-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The x86-64 frame pointer-based unwind method will accept values that aren't valid for the frame pointer register and the return address. This fixes it to reject non-8-byte-aligned frame pointers, as well as non-canonical addresses for the return address it finds. A colleague of mine asked me why Breakpad gave a bad stack for a crash in our crash-stats system: https://crash-stats.mozilla.com/report/index/a472c842-2c7b-4ca7-a267-478cf2160405 Digging in, it turns out that the function in frame 0 is a leaf function, so MSVC doesn't generate an entry in the unwind table for it, so dump_syms doesn't produce a STACK CFI entry for it in the symbol file. The stackwalker tries frame pointer unwinding, and %rbp is set to a value that sort-of works, so it produces a garbage frame 1 and then is lost. Either of the two checks in this patch would have stopped the stackwalker from using the frame pointer. It's possible we could do something smarter on the dump_syms side, like enumerating all functions and outputing some default STACK CFI rule for those that don't have unwind info, but that wouldn't fix crashes from existing builds without re-dumping symbols for them. In any event, these checks should always pass for valid frame pointer-using functions. R=mark@chromium.org BUG=https://bugzilla.mozilla.org/show_bug.cgi?id=1263001 Review URL: https://codereview.chromium.org/1902783002 .
* Issue in StackwalkerAMD64::GetCallerByFramePointerRecovery.Ivan Penkov2015-10-151-9/+25
| | | | | | | | | | | | | | There is an issue in StackwalkerAMD64::GetCallerByFramePointerRecovery. Occasionally it produces invalid frames (instruction pointer == 0) which prevents the AMD64 stack walker from proceeding to do stack scanning and instead leads to premature termination of the stack walking process. For more details: http://crbug/537444 BUG= R=mark@chromium.org Review URL: https://codereview.chromium.org/1408973002 .
* Add frame pointer recovery to the AMD64 Stackwalker.rsesek@chromium.org2014-07-181-2/+52
| | | | | | | | | BUG=https://code.google.com/p/chromium/issues/detail?id=393594 R=mark@chromium.org Review URL: https://breakpad.appspot.com/10664002 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1350 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Allow setting a limit on the number of frames to be recovered by stack scanning.ted.mielczarek@gmail.com2013-08-191-2/+3
| | | | | | 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
* More robust stack walks when the IP address in the context frame is invalid ↵ivan.penkov@gmail.com2013-06-261-4/+4
| | | | | | | | | | | | | (or not in a known module). This is achieved by: 1. Extending the span of the scan for return address in the conext frame. Initially, I wanted to extend the span of the scan for all frames but then I noticed that there is code for ARM already that is extending the search only for the context frame. This kind of makes sense so I decided to reuse the same idea everywhere. 2. Attempting to restore the EBP chain after a successful scan for return address so that the stackwalker can switch back to FRAME_TRUST_CFI for the rest of the frames when possible. I also fixed the lint errors in the files touched. Review URL: https://breakpad.appspot.com/605002 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1193 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Make x86-64 stack walking work for Native Client minidumpsmseaborn@chromium.org2013-05-081-0/+11
| | | | | | | | | | | | | | For NaCl, a stack walker should ignore the top 32 bits of %rip, %rsp and %rbp, otherwise it will try to read from %r15-extended stack addresses and look up symbol info for %r15-extended code addresses, which will fail. BUG=https://code.google.com/p/nativeclient/issues/detail?id=3424 TEST=tested manually with a NaCl minidump Review URL: https://breakpad.appspot.com/591002 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1173 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Use stdint types everywhereted.mielczarek@gmail.com2013-03-061-4/+4
| | | | | | R=mark at https://breakpad.appspot.com/535002/ git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1121 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Print the correct return address, even on architectures where ↵jimblandy2013-01-221-8/+11
| | | | | | | | | StackFrame::instruction is offset. a=bruce.dawson, r=jimblandy git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1105 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Move scoped_ptr.h to commonted.mielczarek@gmail.com2013-01-171-1/+1
| | | | | | R=mark at https://breakpad.appspot.com/509002/ git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1096 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Allow processing dumps with missing stack memory for some threadsted.mielczarek@gmail.com2012-11-061-2/+2
| | | | | | r=mkrebs at https://breakpad.appspot.com/413002/ git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1077 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Refactor the logic of resolving source line info into helper class.SiyangXie@gmail.com2012-10-101-20/+19
| | | | | | | http://breakpad.appspot.com/459002/ git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1068 4c0a9323-5329-0410-9bdc-e9ce6186880e
* In the AMD64 stackwalker, use heuristics to provide %rbp more often, asjimblandy2012-04-251-9/+28
| | | | | | | | | | subsequent frames are usually unable to use CFI if they don't have an %rbp value. a=mrmiller, r=jimb git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@960 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Fix some apparently longstanding crash bugs in Stackwalker implementations ↵ted.mielczarek2011-01-241-1/+1
| | | | | | | | when resolver is NULL. R=mark at http://breakpad.appspot.com/257001 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@761 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Add stack-scanning fallback to Stackwalker{AMD64,ARM}.ted.mielczarek2010-10-011-1/+36
| | | | | | R=jimb at http://breakpad.appspot.com/206001/show git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@704 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Refactor some bits of StackWalkerX86 / StackFrameX86 out into their ↵ted.mielczarek2010-10-011-0/+2
| | | | | | | | 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
* Cleanup: Remove a useless check.thestig@chromium.org2010-08-261-8/+6
| | | | | | Review URL: http://breakpad.appspot.com/174001 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@670 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Breakpad processor: Support AMD64 stack unwinding driven by DWARF CFI.jimblandy2010-03-161-41/+101
| | | | | | | | | | | 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
* Breakpad: Update copyright notice years on all files changed in 2010.jimblandy2010-02-091-1/+1
| | | | | | | | | | 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
* Breakpad processor: Don't pass Windows stack walking information to all walkers.jimblandy2010-01-141-3/+1
| | | | | | | | | | | | | | | | | | | | | 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
* Issue 49012: Breakpad Processor: Rename 'StackFrameInfo' structure to ↵jimblandy2009-12-231-1/+1
| | | | | | | | | | | | | | | '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
* Issue 196 - Breakpad processor support for x86-64. r=mentoted.mielczarek2007-10-311-0/+131
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@227 4c0a9323-5329-0410-9bdc-e9ce6186880e
generated by cgit v1.2.1 (git 2.18.0) at 2024-11-16 10:33:19 +0000