aboutsummaryrefslogtreecommitdiff
path: root/src/processor
Commit message (Collapse)AuthorAgeFilesLines
* The "CPU architecture" field is being filled from the wrong part ofmmandlis@chromium.org2015-08-266-25/+106
| | | | | | | | | | | | | | | | | | | the microdump. The microdump OS/arch line looks like: O A arm 04 armv7l 3.4.0-perf-g4d6e88e #1 SMP PREEMPT Mon Mar 30 19:09:30 2015 and currently the field that says "armv7l" or "aarch64" is being used to fill in the CPU arch field in crash. The problem is that on a 64-bit device this field *always* says "aarch64" even when running in a 32-bit process, and so currently the crash reports for aarch64 are a mix of 32-bit and 64-bit crashes. We should be using the first field instead, which just says "arm" or "arm64" and reflects the actual version of webview (32-bit or 64-bit) which is running. BUG= R=primiano@chromium.org Review URL: https://codereview.chromium.org/1306983003 . git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1498 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Add check for Linux minidump ending on bad write for exploitability rating.Liu.andrew.x@gmail.com2015-08-2111-8/+569
| | | | | | | | | | | | | | | If a crash occurred as a result to a write to unwritable memory, it is reason to suggest exploitability. The processor checks for a bad write by disassembling the command that caused the crash by piping the raw bytes near the instruction pointer through objdump. This allows the processor to see if the instruction that caused the crash is a write to memory and where the target of the address is located. R=ivanpe@chromium.org Review URL: https://codereview.chromium.org/1273823004 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1497 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Don't use strtok_s for mingw buildsted.mielczarek@gmail.com2015-08-203-2/+4
| | | | | | | R=ivanpe at https://codereview.chromium.org/1292503005/ git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1496 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Fix inttypes format macros in src/processor/proc_maps_linux.ccprimiano@chromium.org2015-08-191-1/+4
| | | | | | | | | | | | crrev.com/1298443002 has introduced a build failure by re-defining __STDC_FORMAT_MACROS. Fixing it. BUG= R=mark@chromium.org, ted.mielczarek@gmail.com Review URL: https://codereview.chromium.org/1303493003 . git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1493 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Fix proc_maps_linux compile for non-Linuxted.mielczarek@gmail.com2015-08-171-4/+2
| | | | | | | R=ivanpe at https://codereview.chromium.org/1298443002/ git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1491 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Add check for executable stack/heap when rating Linux exploitability.Liu.andrew.x@gmail.com2015-08-155-3/+30
| | | | | | | | | | | This CL also consequentially adds a public method to get the number of mappings in a Linux minidump. R=ivanpe@chromium.org Review URL: https://codereview.chromium.org/1291603002 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1488 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Add check to see if stack pointer is off the stack according to the memoryLiu.andrew.x@gmail.com2015-08-155-1/+33
| | | | | | | | | | mappings when rating Linux exploitability. R=ivanpe@chromium.org Review URL: https://codereview.chromium.org/1286033002 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1487 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Fix format specifier in proc maps to support 32-bit architectures.Liu.andrew.x@gmail.com2015-08-131-4/+4
| | | | | | | | R=ivanpe@chromium.org Review URL: https://codereview.chromium.org/1288323003 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1486 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Actually remove removed filested.mielczarek@gmail.com2015-08-133-0/+0
| | | | git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1485 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Remove some old unused code, add a missing includeted.mielczarek@gmail.com2015-08-133-648/+0
| | | | | | | | R=lei at https://codereview.chromium.org/1211963002 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1484 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Fix format specifier in proc maps to support 32-bit architectures.Liu.andrew.x@gmail.com2015-08-121-1/+1
| | | | | | | | R=ivanpe@chromium.org Review URL: https://codereview.chromium.org/1280853003 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1483 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Allow Print() to be called by const instances of MinidumpLinuxMaps andLiu.andrew.x@gmail.com2015-08-121-2/+2
| | | | | | | | | | MinidumpLinuxMapsList. R=ivanpe@chromium.org Review URL: https://codereview.chromium.org/1287803002 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1482 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Change Print method of MinidumpLinuxMaps and MinidumpLinuxMapsList to printLiu.andrew.x@gmail.com2015-08-112-1/+2
| | | | | | | | contents of /proc/<pid>/maps instead of just the files mapped to memory. Review URL: https://codereview.chromium.org/1273123002 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1481 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Workaround for range map overlaps caused by Android package relocation.ivanpe@chromium.org2015-08-101-6/+25
| | | | | | | | | | | | | | If there is a range overlap, the cause may be the client correction applied for Android packed relocations. If this is the case, back out the client correction and retry. Patch from Simon Baldwin <simonb@chromium.org>. https://code.google.com/p/chromium/issues/detail?id=509110 R=simonb@chromium.org Review URL: https://codereview.chromium.org/1275173005 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1480 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Fix potential null pointer dereference.Liu.andrew.x@gmail.com2015-07-311-8/+15
| | | | | | | | | | | | If a MinidumpLinuxMapsList was created and destroyed without its Read method, the program would have a segmentation fault because the destructor did not check for a null maps_ field. Additional changes include additional supplementary null checks, a potential memory leak fix, and some comment removal. Review URL: https://codereview.chromium.org/1271543002 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1478 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Remove unnecessary dependencies.Liu.andrew.x@gmail.com2015-07-291-2/+0
| | | | | | Review URL: https://codereview.chromium.org/1266493002 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1477 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Add support for Linux memory mapping stream and remove ELF header usageLiu.andrew.x@gmail.com2015-07-288-205/+506
| | | | | | | | | | | | | | | | | | | | | | | | | | | when checking exploitability rating. Linux minidumps do not support MD_MEMORY_INFO_LIST_STREAM, meaning the processor cannot retrieve its memory mappings. However, it has its own stream, MD_LINUX_MAPS, which contains memory mappings specific to Linux (it contains the contents of /proc/self/maps). This CL allows the minidump to gather information from the memory mappings for Linux minidumps. In addition, exploitability rating for Linux dumps now use memory mappings instead of checking the ELF headers of binaries. The basis for the change is that checking the ELF headers requires the minidumps to store the memory from the ELF headers, while the memory mapping data is already present, meaning the size of a minidump will be unchanged. As a result, of removing ELF header analysis, two unit tests have been removed. Arguably, the cases that those unit tests check do not merit a high exploitability rating and do not warrant a solid conclusion that was given earlier. R=ivanpe@chromium.org Review URL: https://codereview.chromium.org/1251593007 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1476 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Add ELF header analysis when checking for instruction pointer in code.Liu.andrew.x@gmail.com2015-07-169-10/+207
| | | | | | | | | | | | | | If the minidump module containing the instruction pointer has memory containing the ELF header and program header table, when checking the exploitability rating, the processor will use the ELF header data to determine if the instruction pointer lies in an executable region of the module, rather than just checking if it lies in a module. R=ivanpe@chromium.org Review URL: https://codereview.chromium.org/1233973002 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1472 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Set exception whitelist check as earlier check instead of last check.Liu.andrew.x@gmail.com2015-07-071-15/+15
| | | | | | | | | | | | | | | When I first added the exception whitelist, I meant to put the check before checking the location of the instruction pointer. (I didn't notice that it was after the other check until now.) The whitelist check is to quickly rule out minidumps, and if checking the instruction pointer provided any useful information, it would be pretty indicative that the exception causing the dump is interesting. R=ivanpe@chromium.org Review URL: https://codereview.chromium.org/1211253009 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1469 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Use general instruction/stack pointer convenience method instead of manuallyLiu.andrew.x@gmail.com2015-06-303-33/+55
| | | | | | | | | | | | | | finding the instruction/stack pointer for exploitability rating. There was already a method that found the instruction pointer, so the files for exploitability ratings had repeated code. Also a method for finding the stack pointer is implemented in this CL. R=ivanpe@chromium.org Review URL: https://codereview.chromium.org/1210943005 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1468 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Checking for benign exceptions that trigger a minidump.Liu.andrew.x@gmail.com2015-06-303-3/+62
| | | | | | | | | | | | | If the exception reponsible for the crash is benign, such as a floating point exception, we can rule out the possibility that the code is exploitable. This CL checks for such exceptions and marks the dump as not exploitable if such an exception is found. R=ivanpe@chromium.org Review URL: https://codereview.chromium.org/1212383004 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1467 4c0a9323-5329-0410-9bdc-e9ce6186880e
* This CL adds support for ARM and ARM64 architectures when calculatingLiu.andrew.x@gmail.com2015-06-301-1/+8
| | | | | | | | | | | | | | exploitability ratings. The stackwalker will now grab the instruction pointers for ARM and ARM64 architectures, so checking exploitability on ARM and ARM64 will no longer return EXPLOITABILITY_ERR_PROCESSING. R=ivanpe@chromium.org Review URL: https://codereview.chromium.org/1216063004 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1466 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Checking location of the instruction pointer to see if it isLiu.andrew.x@gmail.com2015-06-256-0/+71
| | | | | | | | | | | | | | | | in valid code for Linux exploitability rating. This CL adds to the Linux exploitability checker by verifying that the instruction pointer is in valid code. Verification is done by obtaining a memory mapping of the crash and checking if the instruction pointer lies in an executable region. If there is no memory mapping, the instruction pointer is checked to determine if it lies within a known module. R=ivanpe@chromium.org Review URL: https://codereview.chromium.org/1210493003 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1464 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Fix signal propagation logic for Linux/Android exception handler.primiano@chromium.org2015-06-221-2/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current code is relying on info->si_pid to figure out whether the exception handler was triggered by a signal coming from the kernel (that will re-trigger until the cause that triggered the signal has been cleared) or from user-space e.g., kill -SIGNAL pid, which will NOT automatically re-trigger in the next signal handler in the chain. While the intentions are good (manually re-triggering user-space signals), the current implementation mistakenly looks at the si_pid field in siginfo_t, assuming that it is coming from the kernel if si_pid == 0. This is wrong. siginfo_t, in fact, is a union and si_pid is meaningful only for userspace signals. For signals originated by the kernel, instead, si_pid overlaps with si_addr (the faulting address). As a matter of facts, the current implementation is mistakenly re-triggering the signal using tgkill for most of the kernel-space signals (unless the fault address is exactly 0x0). This is not completelly correct for the case of SIGSEGV/SIGBUS. The next handler in the chain will stil see the signal, but the |siginfo| and the |context| arguments of the handler will be meaningless (retriggering a signal with tgkill doesn't preserve them). Therefore, if the next handler in the chain expects those arguments to be set, it will fail. Concretelly, this is causing problems to WebView. In some rare circumstances, the next handler in the chain is a user-space runtime which does SIGSEGV handling to implement speculative null pointer managed exceptions (see as an example http://www.mono-project.com/docs/advanced/runtime/docs/exception-handling/) The fix herein proposed consists in using the si_code (see SI_FROMUSER macros) to determine whether a signal is coming form the kernel (and therefore just re-establish the next signal handler) or from userspace (and use the tgkill logic). Repro case: This issue is visible in Chrome for Android with this simple repro case: - Add a non-null pointer dereference in the codebase: *((volatile int*)0xbeef) = 42 Without this change: the next handler (the libc trap) prints: F/libc ( 595): Fatal signal 11 (SIGSEGV), code 1, fault addr 0x487 where 0x487 is actually the PID of the process (which is wrong). With this change: the next handler prints: F/libc ( 595): Fatal signal 11 (SIGSEGV), code 1, fault addr 0xbeef which is the correct answer. BUG=chromium:481937 R=mark@chromium.org Review URL: https://breakpad.appspot.com/6844002. git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1461 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Microdump processor: be more tolerant for different logcat formatsprimiano@chromium.org2015-04-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | The current processor implementation is grepping for /google-breakpad( in the logcat lines, to filter out microdump lines, which by default look like this: W/google-breakpad( 3728): -----BEGIN BREAKPAD MICRODUMP----- Turns out that logcat format can vary, when passing optional arguments, and produce something like the following: 04-13 12:30:35.563 6531 6531 W google-breakpad: -----BEGIN ... In the latter case, the "/google-breakpad(" filter is too aggressive. This change is relaxing it, so it is compatible also with non-default logcat arguments. BUG=640 R=mmandlis@chromium.org Review URL: https://breakpad.appspot.com/2864002 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1442 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Add address and reason for IN_PAGE_ERROR.mark@chromium.org2015-04-104-3/+6516
| | | | | | | | | | | | | | ACCESS_VIOLATION and IN_PAGE_ERROR both specify read/write/dep flags and address. ACCESS_VIOLATION currently reports these, but IN_PAGE_ERROR does not. This change makes IN_PAGE_ERROR report this information as well, and also the additional NTSTATUS value for the underlying cause. Patch by bungeman@chromium.org Review URL: https://breakpad.appspot.com/1794002/ git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1441 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Formatting tweak for https://breakpad.appspot.com/9774002, add more newlinested.mielczarek@gmail.com2015-02-271-4/+5
| | | | git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1430 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Add stack contents output functionality to minidump_stackwalkhashimoto@chromium.org2015-02-274-14/+185
| | | | | | | | | | | | | | | | | This feature is enabled only when "-s" is provided as a commandline option. minidump_stackwalk.cc: - Add a new commandline option "-s" to output stack contents. - Instantiate Minidump object in PrintMinidumpProcess() to keep it alive longer so that accessing process_state.thread_memory_regions() in stackwalk_common.cc doesn't result in use-after-free. stackwalk_common.cc: - Add a new function PrintStackContents() to output stack contents. R=mark@chromium.org Review URL: https://breakpad.appspot.com/9774002 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1429 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Remove unneeded definitions of O_BINARYvapier@chromium.org2015-01-282-2/+0
| | | | | | | Review URL: https://breakpad.appspot.com/6684002/ git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1418 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Modify minidump_stackwalk to be more tolerant of overlapping ranges.wfh@chromium.org2014-12-201-6/+20
| | | | | | | | | | | These ranges can be seen in some Android minidumps. BUG=chromium:439531 R=mark@chromium.org Review URL: https://breakpad.appspot.com/9744002 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1412 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Microdumps: support aarch64 and lib mapping from APKprimiano@chromium.org2014-12-0218-766/+148919
| | | | | | | | | | | | | | | | | | - Filter modules by prot flags (only +x) not extensions. It wouldn't otherwise catch the case of Chrome mapping the library from the apk (which is mapped r-x but doesn't end in .so). - Use compile-time detection of target arch, in order to cope with multilib OSes, where uname() doesn't reflect the run-time arch. - Add OS information and CPU arch / count. - Add support for aarch64. - Add tests and stackwalk expectations for aarch64. - Fix a potential overflow bug in the processor. - Rebaseline the tests using smaller symbols. - Fix microdump_writer_unittest.cc on 32-bit host. BUG=chromium:410294 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1407 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Surfacing the process create time in google_breakpad::ProcessStateivanpe@chromium.org2014-11-257-9/+106
| | | | | | | | | | | | | | | | | | | | | | | | | and updating minidump_stackwalk to show process uptime. I tested this with a minidump from Chrome and I got a result that is inline with what the Windows debugger is showing for that dump: minidump_stackwalk output: -------------------------- Process uptime: 601 seconds WinDBG output: -------------- Process Uptime: 0 days 0:10:01.000 I didn't update the machine readable output of minidump_stackwalk on purpose in order to avoid breaking someone that uses it. It can be added later to the machine output if needed. R=mark@chromium.org Review URL: https://breakpad.appspot.com/7754002 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1406 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Introduce microdump_stackwalk comand line executableprimiano@chromium.org2014-11-258-734/+1354
| | | | | | | | | | | | | | | This introduces the microdump_stackwalk binary which takes advantage of the MicrodumpProcessor to symbolize microdumps. Its operation is identical to the one of minidump_stackwalk. This CL, in fact, is also refactoring most of the common bits into stackwalk_common. BUG=chromium:410294 R=mmandlis@chromium.org Review URL: https://breakpad.appspot.com/4704002 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1405 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Microdump processing implementationmmandlis@chromium.org2014-11-197-4/+854
| | | | | | | | | | | | According to design document: http://goo.gl/B3wIRN This is an initial implementation version, support ARM architecture only. BUG=chromium:410294 R=primiano@chromium.org Review URL: https://breakpad.appspot.com/5714003 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1403 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Add inttypes for windows in dump_contextmmandlis@chromium.org2014-09-191-0/+10
| | | | | | | | | BUG=https://code.google.com/p/google-breakpad/issues/detail?id=606 R=primiano@chromium.org Review URL: https://breakpad.appspot.com/6734002 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1381 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Update processor.gyp file with new files added as part of microdumpmmandlis@chromium.org2014-09-101-0/+4
| | | | | | | | | | | | | | processing upcoming implementation. dump_context.cc and dump_object.cc added in r/1370 microdump_processor.cc and microdump_processor_unittest.cc added in r/1372 BUG=chromium:410294 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1373 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Introduce stub microdump processor classes.mmandlis@chromium.org2014-09-102-0/+105
| | | | | | | | | | | | | Adds the interfaces for MicrodumpProcessor (very similar to MinidumpProcessor) and corresponding unittest stubs. These stubs are required for multi-side integration and to start rolling the updated processor library into the dependent projects. BUG=chromium:410294 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1372 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Refactoring in preparation for microdump processingmmandlis@chromium.org2014-09-0811-557/+699
| | | | git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1370 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Add GYP build for the src/tools directory on Mac and Linux.rsesek@chromium.org2014-07-242-0/+232
| | | | | | | | | | | | | | | This GYP-ifies the src/processor and src/common directories on those platforms as well. The Makefile build uses much more granular unittest executables, so the new processor_unittests does not yet link because of multiple main() symbols, but this will be fixed later. Update issue 575 R=mark@chromium.org Review URL: https://breakpad.appspot.com/10674002 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1358 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Add frame pointer recovery to the AMD64 Stackwalker.rsesek@chromium.org2014-07-183-3/+61
| | | | | | | | | 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
* Stringify minidump stream_type constants in minidump_dump outputted.mielczarek@gmail.com2014-07-112-19/+88
| | | | | | R=mark at https://breakpad.appspot.com/3704002/ git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1347 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Don't free pointer in BasicCodeModules::BasicCodeModules before possibly ↵ted.mielczarek@gmail.com2014-07-101-3/+3
| | | | | | | | | using it A=Jim Chen <nchen@mozilla.com> R=ted at https://bugzilla.mozilla.org/show_bug.cgi?id=1033006 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1346 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Update output for test minidump_dump_test.ivanpe@chromium.org2014-06-251-19/+20
| | | | | | | | R=mark@chromium.org Review URL: https://breakpad.appspot.com/10654002 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1340 4c0a9323-5329-0410-9bdc-e9ce6186880e
* minidump_dump: bug fixes.mark@chromium.org2014-06-171-30/+53
| | | | | | | | | | | | | | | | | | | | - Convert time_t values to UTC correctly. It is incorrect to cast a uint32_t* to time_t* because the two types may have different widths. This is the case on many 64-bit systems, where time_t is a 64-bit signed integer. Conversion is unified in a single function, and additional uses of time_t in minidump files not previously displayed in UTC are now displayed. - Interpret the IMAGE_DEBUG_MISC structure correctly. - When printing MINIDUMP_SYSTEM_INFO structures, always show the "x86" side of the union, and state whether it's expected to be valid. (Existing Breakpad-produced non-Windows minidumps for x86_64 use the "x86" side of union, but Windows minidumps for x86_64 use the "other" side, so I want to print both.) R=ivanpe@chromium.org Review URL: https://breakpad.appspot.com/5674002 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1339 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Add missing MD_MISCINFO_FLAGS1_BUILDSTRING. Revise documentation to clarifymark@chromium.org2014-06-031-44/+144
| | | | | | | | | | | | | that it is not enough to check the size of an MDRawMiscInfo stream to verify member validity, the flags1 field needs to be consulted as well. Update minidump_dump to correctly consider the validity of all fields in this structure. R=ivanpe@chromium.org Review URL: https://breakpad.appspot.com/3694002 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1336 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Print more x86-64 registers in minidump_stackwalkted.mielczarek@gmail.com2014-05-301-4/+22
| | | | | | | | R=mark@chromium.org Review URL: https://breakpad.appspot.com/7654002 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1335 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Add support for CFI based stack walking on Arm64.rmcilroy@chromium.org2014-05-063-5/+420
| | | | | | | | | | | | This CL adds CFI based stack walking support for Arm64 to BreakPad along with unit tests. The Arm64 CFI stack walker is based on the Arm CFI stack walker BUG=367367,335641,354405 R=blundell@chromium.org, mark@chromium.org Review URL: https://breakpad.appspot.com/1664002 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1325 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Fix warnings from the Windows build.thestig@chromium.org2013-12-171-2/+10
| | | | | | | | | | | These warnings are fatal in my GYP-generated debug build. The warnings can be seen on Linux/Mac with -Wshorten-64-to-32. R=mark@chromium.org Review URL: https://breakpad.appspot.com/944002 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1264 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Run svn propdel svn:executable on source code files.thestig@chromium.org2013-12-171-0/+0
| | | | | | Review URL: https://breakpad.appspot.com/934002 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1263 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Fixing several instances of wrong printf format specifiers.ivan.penkov@gmail.com2013-12-031-3/+3
| | | | | | Review URL: https://breakpad.appspot.com/794002 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1241 4c0a9323-5329-0410-9bdc-e9ce6186880e
generated by cgit v1.2.1 (git 2.18.0) at 2024-11-05 14:25:55 +0000