aboutsummaryrefslogtreecommitdiff
path: root/src/google_breakpad/processor/stackwalker.h
Commit message (Collapse)AuthorAgeFilesLines
* Handle very large stack tracesLeonard Mosescu2017-07-121-1/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Populate stack frames with unloaded module info.Joshua Peraza2017-01-191-0/+7
| | | | | | | | | | | | | | | | | | | 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>
* Refactoring in preparation for microdump processingmmandlis@chromium.org2014-09-081-2/+2
| | | | git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1370 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/+15
| | | | | | 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
* Detect corrupt symbol files during minidump processing. Recover from the ↵ivan.penkov@gmail.com2013-07-111-3/+6
| | | | | | | | | | | | | | | | | | | | | errors and use the good data if possible. More specifically: - Detect corrupt symbols during minidump processing and provide the list of modules with corrupt symbols in the ProcessState. This will allow listing the corrupt symbol files in the final crash report. - Skip and recover from symbol data parse errors - don't give up until 100 parse errors are seen. - In order to recover from '\0' (null terminator) in the middle of a symbol file, a couple of methods have to be updated to require both buffer pointer and length. Previously they required only a buffer pointer (char *) and the size of the buffer was evaluated using strlen which is not reliable when the data is corrupt. Most of the changes are due to these signature updates. - Added and updated unittests. Also, updated minidump_stackwalk to show a WARNING for corrupt symbols. Output looks like this: ... Loaded modules: 0x000da000 - 0x000dafff Google Chrome Canary ??? (main) 0x000e0000 - 0x0417dfff Google Chrome Framework 0.1500.0.3 (WARNING: Corrupt symbols, Google Chrome Framework, 4682A6B4136436C4BFECEB62D498020E0) 0x044a8000 - 0x04571fff IOBluetooth 0.1.0.0 ... Review URL: https://breakpad.appspot.com/613002 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1200 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-2/+9
| | | | | | | | | | | | | (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
* Don't print an error when a user-set max frames limit has been reached in ↵ted.mielczarek@gmail.com2013-04-161-1/+9
| | | | | | | | the stackwalker Patch by Julian Seward <jseward@acm.org>, R=ted at https://bugzilla.mozilla.org/show_bug.cgi?id=859745 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1150 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Keeping track of modules without symbols during crash report processing.ivan.penkov@gmail.com2013-03-061-1/+11
| | | | | | | | http://breakpad.appspot.com/534002/ git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1126 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
* Allow StackwalkerARM to scan much farther to find the caller of the context ↵ted.mielczarek@gmail.com2012-12-041-2/+4
| | | | | | | | frame R=jimb at https://breakpad.appspot.com/501002/ git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1086 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Refactor the logic of resolving source line info into helper class.SiyangXie@gmail.com2012-10-101-41/+28
| | | | | | | http://breakpad.appspot.com/459002/ git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1068 4c0a9323-5329-0410-9bdc-e9ce6186880e
* This change allows compiling the google-breakpad code using a global ↵ivan.penkov@gmail.com2012-06-281-1/+3
| | | | | | ::string class instead of std::string. For more details take a look at common/using_std_string.h git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@974 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Fix class/struct mismatches in forward declarations.benchan@chromium.org2012-03-301-1/+1
| | | | | | | | | | This patch fixes some compiler warnings when compiling with clang. BUG=none TEST=Compile with clang and run unit tests. Review URL: https://breakpad.appspot.com/368001 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@937 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Support for .raSearch in the x86 stackwalkermark@chromium.org2012-02-231-3/+12
| | | | | | | Patch by Benjamin Smedberg <bsmedberg@gmail.com> git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@927 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Double stack scanning length in stackwalkerted.mielczarek2010-10-191-1/+1
| | | | | | R=jimb at http://breakpad.appspot.com/215001/show git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@715 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Refactor some bits of StackWalkerX86 / StackFrameX86 out into their ↵ted.mielczarek2010-10-011-2/+35
| | | | | | | | 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
* Limit the number of frames we try to walk to prevent runaway processors.thestig@chromium.org2010-08-261-1/+7
| | | | | | Review URL: http://breakpad.appspot.com/175001 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@672 4c0a9323-5329-0410-9bdc-e9ce6186880e
* add missing <string> include from r541ted.mielczarek2010-03-031-0/+1
| | | | git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@544 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Fix to cache NOT_FOUND results from symbol supplier on a per-minidump basis nealsid2010-03-031-2/+8
| | | | | | | | | | | http://breakpad.appspot.com/64001 R=ted.mielczarek, brdevmn A=nealsid git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@543 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-8/+5
| | | | | | | | | | | | | | | | | | | | | 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-2/+2
| | | | | | | | | | | | | | | '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
* Let x86 stackwalker scan stack in cases where program evaluation fails. ↵ted.mielczarek2009-10-081-0/+11
| | | | | | Original patch by Jeff Muizelaar <jmuizelaar@mozilla.com> with some changes by me. r=mento at http://breakpad.appspot.com/32003/show git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@409 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Truncated Windows/x86 stacks when using FPO. Add stack scanning to recovermmentovai2007-04-201-4/+4
| | | | | | | | | instruction and frame pointers with better reliability. r=bryner http://groups.google.com/group/google-breakpad-dev/browse_thread/thread/e74af03fb0629aa0 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@146 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Rename Airbag to Breakpad.mmentovai2007-02-141-0/+140
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@122 4c0a9323-5329-0410-9bdc-e9ce6186880e
generated by cgit v1.2.1 (git 2.18.0) at 2024-06-29 16:43:37 +0000