Here is the symbol parser output:
E0906 11:27:06.051507 22535 basic_source_line_resolver.cc:76] Line 380187: ParseLine failed
E0906 11:27:06.051614 22535 basic_source_line_resolver.cc:76] Line 380188: ParseLine failed
E0906 11:27:06.051648 22535 basic_source_line_resolver.cc:76] Line 380190: ParseLine failed
E0906 11:27:06.051679 22535 basic_source_line_resolver.cc:76] Line 380191: ParseLine failed
E0906 11:27:06.200814 22535 basic_source_line_resolver.cc:76] Line 446729: ParseLine failed
Here are the contents of the Breakpad symbol file:
FUNC 440d60 49 0 __copy_helper_block_
440d60 b 0 3160 <<<----------- the third number is the line number
440d6b 3e 0 3160 <<<---------------------------- same here
FUNC 440db0 36 0 __destroy_helper_block_
440db0 a 0 3160 <<<---------------------------- same here
440dba 2c 0 3160 <<<---------------------------- same here
Review URL: https://breakpad.appspot.com/629002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1214 4c0a9323-5329-0410-9bdc-e9ce6186880e
Tested with a minidump containing a version 3 structure to validate the string conversion routines. Interestingly enough the time_zone names does not appear to be abbreviation as the documentation was suggesting but full names, e.g. Eastern Standard Time:
MDRawMiscInfo
size_of_info = 232
flags1 = 0xf7
process_id = 0x54c4
process_create_time = 0x51a9323c
process_user_time = 0x1
process_kernel_time = 0x0
processor_max_mhz = 3100
processor_current_mhz = 1891
processor_mhz_limit = 3100
processor_max_idle_state = 0x1
processor_current_idle_state = 0x1
The new fileds follow:
process_integrity_level = 0x1000
process_execute_flags = 0x4d
protected_process = 0
time_zone_id = 2
time_zone.bias = 300
time_zone.standard_name = Eastern Standard Time
time_zone.daylight_name = Eastern Daylight Time
Review URL: https://breakpad.appspot.com/617002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1204 4c0a9323-5329-0410-9bdc-e9ce6186880e
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
../../breakpad/src/processor/tokenize.cc:65:7: error: logical not is only applied to the left hand side of this comparison [-Werror,-Wlogical-not-parentheses]
if (!remaining > 0) {
^ ~
../../breakpad/src/processor/tokenize.cc:65:7: note: add parentheses after the '!' to evaluate the comparison first
if (!remaining > 0) {
^
( )
../../breakpad/src/processor/tokenize.cc:65:7: note: add parentheses around left hand side expression to silence this warning
if (!remaining > 0) {
^
( )
R=thakis@chromium.org
Review URL: https://breakpad.appspot.com/608002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1196 4c0a9323-5329-0410-9bdc-e9ce6186880e
Since explanatoryDialogText returns something that migth be user input, this
looks like a good change anyhow.
../../breakpad/src/client/mac/sender/crash_report_sender.m:269:38:
error: format string is not a string literal (potentially insecure)
[-Werror,-Wformat-security]
[self explanatoryDialogText],
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
Patch by Nico Weber <thakis@chromium.org>
Review URL: https://breakpad.appspot.com/607002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1195 4c0a9323-5329-0410-9bdc-e9ce6186880e
doesn't see the correct thread stack memory. Instead, it loads garbage
(from offset 0 of the minidump file - well that's not garbage, but it is
not the stack memory region either) and attempts to walk it. A typical
symptom of this issue is when you get a single stack frame after
processing - the context frame - for which you don't need stack memory.
This issue is caused by an invalid RVA in the memory descriptor stored
inside the MINIDUMP_THREAD structure for the thread. Luckily, the
invalid RVA is 0, and the start_of_memory_region appears to be correct,
so this issue can be easily detected and the correct memory region can be
loaded using an RVA specified in the MinidumpMemoryList.
I couldn't find a reasonable description on MSDN regarding
MINIDUMP_MEMORY_DESCRIPTOR.MINIDUMP_LOCATION_DESCRIPTOR having RVA of 0
except maybe for full dumps where the 64-bit version of the structure
(MINIDUMP_MEMORY_DESCRIPTOR64) is used and it has no RVA at all. It has
a 64-bit DataSize which if interpreted as the 32-bit structure will very
likely result in 0 for the RVA:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms680384(v=vs.85).aspx
Anyways, the dump that I looked at was not a full dump so 0 for RVA is a
bit puzzling (at least easily detectable):
...
Microsoft (R) Windows Debugger Version 6.2.9200.20512 X86
Copyright (c) Microsoft Corporation. All rights reserved.
...
User Mini Dump File: Only registers, stack and portions of memory are available
...
MINIDUMP_HEADER:
Version A793 (62F0)
NumberOfStreams 11
Flags 160
0020 MiniDumpWithUnloadedModules
0040 MiniDumpWithIndirectlyReferencedMemory
0100 MiniDumpWithProcessThreadData
Review URL: https://breakpad.appspot.com/606002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1194 4c0a9323-5329-0410-9bdc-e9ce6186880e
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
There's a bug in the new allocator<T> implementation used by wasteful_vector. It inherits the base class' implementation of allocator and doesn't implement allocate() so it goes to the heap instead of the PageAllocator -- the very thing wasteful_vector was trying to avoid! As a side effect it was also leaking heap memory.
Thanks,
-Ivan
Review URL: https://breakpad.appspot.com/599002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1188 4c0a9323-5329-0410-9bdc-e9ce6186880e
NaCl executables have ELF program headers that look like this (for the
original NaCl x86 GCC toolchain):
Program Header:
LOAD off 0x00010000 vaddr 0x00020000 paddr 0x00020000 align 2**16
filesz 0x00017ce0 memsz 0x00017ce0 flags r-x
LOAD off 0x00030000 vaddr 0x10020000 paddr 0x10020000 align 2**16
filesz 0x00001c98 memsz 0x00001c98 flags r--
LOAD off 0x00040000 vaddr 0x10030000 paddr 0x10030000 align 2**16
filesz 0x000025ec memsz 0x00002b88 flags rw-
or this (for the newer NaCl ARM GCC toolchain):
Program Header:
LOAD off 0x00010000 vaddr 0x00020000 paddr 0x00020000 align 2**16
filesz 0x000193b0 memsz 0x000193b0 flags r-x
LOAD off 0x00000000 vaddr 0x10020000 paddr 0x10020000 align 2**16
filesz 0x00000978 memsz 0x00000978 flags r--
LOAD off 0x00001000 vaddr 0x10031000 paddr 0x10031000 align 2**16
filesz 0x00000abc memsz 0x00000fac flags rw-
Fix GetLoadingAddress() to return the start address of the first
segment, 0x20000, in these cases. Looking at p_offset for this isn't
correct, and the first segment doesn't have p_offset == 0 here because
NaCl can't map the ELF file headers as part of the first segment
(which is for validatable code only).
BUG= https://code.google.com/p/nativeclient/issues/detail?id=3424
TEST= check addresses in output of "dump_syms" when run on NaCl nexe
Patch by Mark Seaborn <mseaborn@chromium.org>
Review URL: https://breakpad.appspot.com/588002/
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1170 4c0a9323-5329-0410-9bdc-e9ce6186880e
This CL adds new utilities to common/windows for handling OMAP information in
PDB files. It then augments PdbSourceLineWriter with explicit OMAP knowledge so
that symbolization will proceed more cleanly for images whose PDB files contain
OMAP information. This makes breakpad handle OMAPped symbol files as cleanly as
WinDbg.
Review URL: https://breakpad.appspot.com/570002/
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1167 4c0a9323-5329-0410-9bdc-e9ce6186880e
