problems.
- The ordering of keys in stl containers cannot change. Make the relevant
members const to guarantee this assumption.
- Add handling and logging for demangle errors.
- Fix a potential double-delete bug if a function passed to AddFunction() is
already present.
BUG=chromium:449214
R=mark@chromium.org
Review URL: https://breakpad.appspot.com/10704002/
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1415 4c0a9323-5329-0410-9bdc-e9ce6186880e
gcc has a single exception setting for all languages. Saying -fno-exceptions
in gcc disables exceptions and cleanups for cc files, but has no effect for mm
files.
In clang, -fno-exceptions only disables c++ exceptions, but keeps objective-c
exceptions and cleanups enabled.
http://llvm.org/viewvc/llvm-project?view=revision&revision=220714 changed
__EXCEPTIONS to be defined for clang when cleanups are enabled, independent of
if c++ exceptions are enabled. (This was necessary to have clang work with
glibc which looks at __EXCEPTIONS to decide if cleanups are enabled.)
Breakpad tried to use __EXCEPTIONS to figure out if c++ exceptions are enabled.
In cc files, this works: -fno-exceptions will disable c++ exceptions and
cleanups. But in mm files, -fno-exceptions will disable c++ exceptions and
objective-c exceptions will still be enabled, and so cleanups must run and hence
__EXCEPTIONS is defined.
To make things work with both old and new compilers, do the try/catch hack in
mm files either if __EXCEPTIONS is not defined (for old compilers) or if the
compiler is clang and __has_feature(cxx_exceptions) isn't set (which will work
for new clangs too, and which cleanly maps to if c++ exceptions are enabled).
Patch by Nico Weber <thakis@chromium.org>
Review URL: https://breakpad.appspot.com/1774002/
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1409 4c0a9323-5329-0410-9bdc-e9ce6186880e
Previously, dump_syms did not handle DW_FORM_ref_addr if it appeared
in DWARF 4 debugging info.
Also fix a DW_FORM_ref_addr case so that it doesn't fall through to
the next switch case when assertions are disabled and the DWARF
version isn't recognised.
The following steps will reproduce the problem when using LLVM 3.4:
cat <<END >example1.c
int main() { return 0; }
END
cat <<END >example2.c
void foo(int x) {}
END
clang -emit-llvm -g -c example1.c -o example1.bc
clang -emit-llvm -g -c example2.c -o example2.bc
llvm-link-3.4 example1.bc example2.bc -o combined.bc
clang combined.bc -o executable
./google-breakpad/build/src/tools/linux/dump_syms/dump_syms executable
When using LLVM bitcode linking in this way, LLVM's backend generates
partially-merged DWARF debugging info in which some of the references
to the "int" type go via "DW_FORM_ref_addr". Since PNaCl uses LLVM
bitcode linking, this dump_syms failure occurs with nexes produced by
the PNaCl toolchain.
BUG= https://code.google.com/p/chromium/issues/detail?id=416368
TEST= see above
R=mark@chromium.org, mcgrathr@chromium.org
Review URL: https://breakpad.appspot.com/5744002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1408 4c0a9323-5329-0410-9bdc-e9ce6186880e
- 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
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
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
Adding an optional parameter --product to symupload.exe. If specified it will be passed to the symbol server as POST parameter 'product'.
As part of this, I'm also fixing:
- Removed the .vcproj file as it can be generated from the .gyp file on demand.
- error C4335: Mac file format detected. Fixed the line endings for omap.cc and dia_util.cc.
- warning C4003: not enough actual parameters for macro 'max'
Symupload.exe was compiled using MSVS 2013 and DIA SDK 12.0.
Review URL: https://breakpad.appspot.com/9734002/
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1402 4c0a9323-5329-0410-9bdc-e9ce6186880e
Microdumps are a very lightweight variant of minidumps. They are meant
to dump a minimal crash report on the system log (logcat on Android),
containing only the state of the crashing thread.
This is to deal with cases where the user has opted out from crash
uploading but we still want to generate meaningful information on the
device to pull a stacktrace for development purposes.
Conversely to conventional stack traces (e.g. the one generated by
Android's debuggerd or Chromium's base::stacktrace) microdumps do NOT
require unwind tables to be present in the target binary. This allows
to save precious binary size (~1.5 MB for Chrome on Arm, ~10 MB on
arm64).
More information and design doc on crbug.com/410294
BUG=chromium:410294
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1398 4c0a9323-5329-0410-9bdc-e9ce6186880e
This change introduces the necessary glue typedefs to deal with the
mismatch introduced by the latest Android NDK (w.r.t. desktop Linux):
- [x86_64] Rename fpregs mxcr_mask -> .mxcsr_mask
- [mips] uc_mcontext.fpregs.fp_r.fp_dregs -> uc_mcontext.fpreg
- [mips] restore the forked user.h
Submitting this on behalf of fdegans@chromium.orgTBR=mark@chromium.org
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1397 4c0a9323-5329-0410-9bdc-e9ce6186880e
Prior to NDK r10c, Breakpad was privately backporting these system
headers. This change is now unforking and removing those headers and
using the ones from the NDK.
Rationale:
- They are finally available in the NDK, so there is no need to keep
maintaining a fork (which was necessary up until recently to support
arm64).
- These forked headers, as they are today, are not compatible with the
latest NDK (i.e. this change is required to roll NDK r10c).
The forked ucontext.h, being removed by this CL, depends on some
transitional features which are not compatible with the NDK release
being targeted here.
After this change, the NDK r10c is now required to build Breakpad on
Android. Note that NDK releases are backwards compatible and contain all
the previous API levels, so this change is NOT effectively enforcing to
build against any particular Android SDK.
Submitting this on behalf of fdegans@chromium.org
BUG=chromium:358831
R=mark@chromium.org, primiano@chromium.org, rmcilroy@chromium.org
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1396 4c0a9323-5329-0410-9bdc-e9ce6186880e
This is a refactoring of the logic which determines the
module name and path for a given MappingInfo in minidump_writer.cc.
Such logic, which will be soon shared also with the upcoming
microdump_writer.cc, is simply being moved to linux_dumper.cc,
extracting a GetMappingEffectiveNameAndPath method.
No behavioral change is intended.
BUG=chromium:410294
R=thestig@chromium.org
Review URL: https://breakpad.appspot.com/7734002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1392 4c0a9323-5329-0410-9bdc-e9ce6186880e
Server is used is done by subtracting the crashing process creation time from
the current time when the crash is generated:
uptime = now - process_creation_time
There was a bug and instead of the process creation time the code was using the
time when the process was registered with the Crash Generation Server.
R=mark@chromium.org
Review URL: https://breakpad.appspot.com/1744002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1391 4c0a9323-5329-0410-9bdc-e9ce6186880e
This change is a pure refactoring of the common bits of minidump_writer.cc
that will be shared soon with the upcoming microdump_writer.cc.
In particular, this CL is extracting the following classes:
- ThreadInfo: handles the state of the threads in the crashing process.
- RawContextCPU: typedef for arch-specific CPU context structure.
- UContextReader: Fills out a dump RawContextCPU structure from the
ucontext struct provided by the kernel (arch-dependent).
- SeccompUnwinder: cleans out the stack frames of the Seccomp sandbox
on the supported architectures.
- MappingInfo: handles information about mappings
BUG=chromium:410294
R=mmandlis@chromium.org
Review URL: https://breakpad.appspot.com/4684002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1388 4c0a9323-5329-0410-9bdc-e9ce6186880e
When parsing /proc/pid/maps, current code merges adjacent entries that
refer to the same library and where the start of the second is equal to
the end of the first, for example:
40022000-40025000 r-xp 00000000 b3:11 827 /system/lib/liblog.so
40025000-40026000 r--p 00002000 b3:11 827 /system/lib/liblog.so
40026000-40027000 rw-p 00003000 b3:11 827 /system/lib/liblog.so
When the system linker loads a library it first reserves all the address
space required, from the smallest start to the largest end address, using
an anonymous mapping, and then maps loaded segments inside that reservation.
If the loaded segments do not fully occupy the reservation this leaves
gaps, and these gaps prevent merges that should occur from occurring:
40417000-4044a000 r-xp 00000000 b3:11 820 /system/lib/libjpeg.so
> 4044a000-4044b000 ---p 00000000 00:00 0
4044b000-4044c000 r--p 00033000 b3:11 820 /system/lib/libjpeg.so
4044c000-4044d000 rw-p 00034000 b3:11 820 /system/lib/libjpeg.so
Where the segments that follow this gap do not contain executable code
the failure to merge does not affect breakpad operation. However, where
they do then the merge needs to occur. Packing relocations in a large
library splits the executable segment into two, resulting in:
73b0c000-73b21000 r-xp 00000000 b3:19 786460 /data/.../libchrome.2160.0.so
> 73b21000-73d12000 ---p 00000000 00:00 0
73d12000-75a90000 r-xp 00014000 b3:19 786460 /data/.../libchrome.2160.0.so
75a90000-75c0d000 rw-p 01d91000 b3:19 786460 /data/.../libchrome.2160.0.so
Here the mapping at 73d12000-75a90000 must be merged into 73b0c000-73b21000
so that breakpad correctly calculates the base address for text.
This change enables the full merge by also merging anonymous maps which
result from unused reservation, identified as '---p' with offset 0, and
which follow on from an executable mapping, into that executable mapping.
BUG=chromium:394703
R=rmcilroy@chromium.org, thestig@chromium.org
Review URL: https://breakpad.appspot.com/7714003
Patch from Simon Baldwin <simonb@chromium.org>.
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1380 4c0a9323-5329-0410-9bdc-e9ce6186880e
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
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
This CL adds three features that will allow the client to upload the report
file.
Three main modifications are made :
- Allow upload url to have a file:// scheme, and write the HTTP request to file
in that case
- Split the request in two parts in case of a file:// scheme, the request
time and the response time. A new API [handleNetworkResponse] is added.
- Give the opportunity to the client to get the configuration NSDictionary
to be able to recreate the breakpad context at response time.
Patch by Olivier Robin <olivierrobin@chromium.org>
Review URL: https://breakpad.appspot.com/2764002/
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1368 4c0a9323-5329-0410-9bdc-e9ce6186880e
Using the vm_region_recurse API with a vm_region_submap_info_64
structure leads to a deviation in the structure when reading the user_tag
field.
Switching to the vm_region_recurse_64 API.
Patch by Olivier Robin <olivierrobin@chromium.org>
BUG=crbug/397133
Review URL: https://breakpad.appspot.com/4664002/
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1363 4c0a9323-5329-0410-9bdc-e9ce6186880e
This adds a new |-g <dSYM path>| flag to dump_syms, to specify the dSYM path for
the target Mach-O argument. The UUIDs and architectures of the two paths must
match in order to dump symbols for this "split module."
This reason for this is that for x86_64 binaries on OS X, the CFI data is stored
in the __TEXT,__eh_frame segment of the Mach-O file, and the data is not copied
into the dSYM by dsymutil. Therefore, just dumping the dSYM doesn't yield CFI
data for x86_64 files, and both the dSYM and the Mach-O file must be dumped in
order to produce a complete Breakpad symbol file. For i386 binaries, the CFI data
is stored in the __DWARF,__debug_frame segment, which is part of the dSYM, so
this isn't necessary.
BUG=https://code.google.com/p/chromium/issues/detail?id=393594R=mark@chromium.org
Review URL: https://breakpad.appspot.com/6704002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1359 4c0a9323-5329-0410-9bdc-e9ce6186880e
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
PageAllocator maps memory via sys_mmap(), implemented in
linux_syscall_support.h. We need to explicitly inform MSan that this memory is
initialized.
Patch by Sergey Matveev <earthdok@chromium.org>
BUG=chromium:394028
Review URL: https://breakpad.appspot.com/2744002/
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1356 4c0a9323-5329-0410-9bdc-e9ce6186880e
This patch makes two changes to breakpad to enable crash reporting to work correctly when the library is inside another file (an archive):
- Do not filter mappings which map an executable at a non-zero offset.
- If such an executable is mapped look in the ELF information for the
shared object name and use that name in the minidump.
Note this change doesn't care about the archive format and isn't Android
specific (though loading the shared library this way is currently only done on Android).
BUG=390618
R=thestig@chromium.org
Review URL: https://breakpad.appspot.com/7684002
Patch from Anton Carver <anton@chromium.org>.
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1355 4c0a9323-5329-0410-9bdc-e9ce6186880e
__system_property_get has been removed from the Android NDK for 'L' so Breakpad
no longer links. This CL just removes the call in WriteOSInformation because
Chrome already passes the build fingerprint as a crash key called "android_build_fp" in the crash report HTTP POST message.
BUG=394841,393903
R=mark@chromium.org
Review URL: https://breakpad.appspot.com/1694002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1351 4c0a9323-5329-0410-9bdc-e9ce6186880e
After handling an uncaught NSException, release the Breakpad object
so there will not be a second crash dump logged.
Prior to this change, for every uncaught NSException handled through
the Breakpad::UncaughtExceptionHandler(), a second crash without
any useful information (generally __cxa_rethrow and std::__terminate)
is recorded.
R=qsr@chromium.org
Review URL: https://breakpad.appspot.com/9664002
Patch from Peter Lee <pkl@chromium.org>.
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1344 4c0a9323-5329-0410-9bdc-e9ce6186880e
This bug manifests itself on Android x64 (in ExceptionHandlerTest::ExternalDumper), but is possible on any platform.
The compiler is unaware of the code which runs in the signal handler which reads this variable. Without volatile the compiler is free to optimise away writes to this variable which it believes are never read.
BUG=381142, 346626
R=thestig@chromium.org
Review URL: https://breakpad.appspot.com/8664002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1343 4c0a9323-5329-0410-9bdc-e9ce6186880e
- 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
This fixes exception_handler.cc:77:8: error: fields must have a constant size:
'variable length array in structure' extension will never be supported
char protected_buffer[PAGE_SIZE] __attribute__((aligned(PAGE_SIZE)));
BUG=None
TEST=breakpad builds on ios8
R=mark@chromium.org
Review URL: https://breakpad.appspot.com/9654002
Patch from Justin Cohen <justincohen@chromium.org>.
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1338 4c0a9323-5329-0410-9bdc-e9ce6186880e
This CL introduces "--sobasedir" command-line option to minidump-2-core.
By default, paths to shared lib files included in generated core file are
formatted as "/var/lib/breakpad/[GUID]libFoobar.so". By using "--sobasedir",
this will be "[user-supplied-path]libFoobar.so".
This option can be used to ease debugging minidump files from developer's local
builds. By specifying "minidump-2-core --sobasedir `pwd`/out/Debug/lib/
foobar.mdmp", user can load the generated core file in gdb without setting up
the symlinks for "/var/lib/breakpad".
BUG=None
A=kouhei@chromium.org
Original code review: https://breakpad.appspot.com/1214002/R=kouhei@chromium.org
Review URL: https://breakpad.appspot.com/1584002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1317 4c0a9323-5329-0410-9bdc-e9ce6186880e
This has a substantial performance improvement over using the getSymbolsByAddr iterator, especially on certain 64bit DLLS. e.g. Time to process chrome_child.dll drops from 51 minutes to 21 secs.
Note: new test data looks different because the ordering of lines is no longer by memory address. This does not affect processing. The test data has been manually compared to old data and matches (except additional PUBLIC symbols). Also, INFO lines are omitted because the source executable files are not checked in, so they are unavailable.
R=ivanpe@chromium.org, mark@chromium.org
Review URL: https://breakpad.appspot.com/1574002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1316 4c0a9323-5329-0410-9bdc-e9ce6186880e
After r1299, the LinuxCoreDumperTest::VerifyDumpWithMultipleThreads and
ElfCoreDumpTest::ValidCoreFile would both hang on Android. This appears to be due to the tkill
signal not being recieved by the thread which is meant to crash, even though tkill returns 0.
This CL retries sending the tkill signal multiple times, which prevents the Hang.
BUG=579
R=thestig@chromium.org
Review URL: https://breakpad.appspot.com/1524002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1313 4c0a9323-5329-0410-9bdc-e9ce6186880e
As part of that:
- Updated MSSymbolServerConverter to also download the executable files from the symbol server and pass them to the PDBSourceLineWriter as it is required for successful conversion of symbols for 64-bit modules.
- Added a .gyp file and target for the ms_symbol_server_converter library.
- Updated PDBSourceLineWriter to allow executable files to be in locations different from the locations of the PDB files.
- Minor style issue:
* #define guards.
* No space before ')' and after '('.
R=mark@chromium.org, wfh@chromium.org
Review URL: https://breakpad.appspot.com/1434002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1309 4c0a9323-5329-0410-9bdc-e9ce6186880e
The ElfCoreDumpTest.ValidCoreFile unit test assumed that the number of
NT_FPREGSET / NT_PRXFPREG notes in the core dump file equals to the number of
threads of the crashed process. This assumption isn't always true as the kernel
skips filling the NT_FPREGSET / NT_PRXFPREG note of a thread if the FPU state
isn't available. The kernel indicates the availability of NT_FPREGSET /
NT_PRXFPREG via the pr_fpvalid field of the NT_PRSTATUS note. This CL modifies
the ElfCoreDumpTest.ValidCoreFile unit test to verify the number of NT_FPREGSET
and NT_PRXFPREG notes based on the pr_fpvalid field of the NT_PRSTATUS notes.
BUG=577
TEST=Run unit tests on x86 and x86_64 Linux platform.
R=vapier@chromium.org
Review URL: https://breakpad.appspot.com/1404002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1303 4c0a9323-5329-0410-9bdc-e9ce6186880e
This is an initial attempt to add Arm64 (aarch64) support to Breakpad for
Linux / Android platforms. This CL adds the Arm64 data structures, but does
not yet implement the Android getcontext support or CPUFillFromThreadInfo /
CPUFillFromUContext.
BUG=354405,335641
R=mark@chromium.org
Review URL: https://breakpad.appspot.com/1354002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1301 4c0a9323-5329-0410-9bdc-e9ce6186880e
The current CreateChildCrash logic is racy when it comes to creating a
crash dump for two reasons:
The main thread that calls kill() on a different thread is guaranteed
the signal will be *queued* when it returns, but not *delivered*. If
the kernel doesn't automatically schedule the receiving thread, but
instead lets the main thread run to the exit() call, then the signal
never triggers a coredump and the whole process simply exits.
The main thread is using kill() to try to deliver a signal to a
specific thread, but that function is for sending signals to a
process. That means the kernel is free to deliver the signal to
any thread in the process and not just the one requested. This
manifests itself as the pr_pid in the coredump not being the one
expected. Instead, we must use tkill() with the tid (which we
already took care of gathering) to deliver to a specific thread.
These are a lot easier to see on a UMP system as contention is heavier.
BUG=chromium:207918
TEST=`dumper_unittest` still passes, and doesn't flake out in a UMP system
TEST=`linux_client_unittest` still passes
R=benchan@chromium.org
Review URL: https://breakpad.appspot.com/1304005
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1299 4c0a9323-5329-0410-9bdc-e9ce6186880e
(instead of C++) it gets upset about the default argument. Instead of
using a default argument I split the function up into two separate
functions.
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1280 4c0a9323-5329-0410-9bdc-e9ce6186880e
The Mac crash key manipulation code was intended to be thread-safe through the
provision of a mutex. The mutex operations were done inside an assert().
assert() is a no-op in NDEBUG (release) builds. Therefore, in release builds,
these operations were occurring without being protected by any mutex at all,
and were nowhere near thread-safe.
BUG=chromium:331268
R=rsesek@chromium.org
Review URL: https://breakpad.appspot.com/1034002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1270 4c0a9323-5329-0410-9bdc-e9ce6186880e
This is Chromium's base/memory/scoped_ptr.h at r98718, which split off
from the google3 version at a later point than Breakpad's copy. It is a
drop in replacement and the only changes are:
- removal of WARN_UNUSED_RESULT.
- moving it into the google_breakpad namespace.
BUG=534
R=mark@chromium.org
Review URL: https://breakpad.appspot.com/964002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1265 4c0a9323-5329-0410-9bdc-e9ce6186880e
- src/common/android/testing/mkdtemp.h:
Fixes a compilation error when using the (recent) NDK r9b,
see comments in the source file for details.
- android/test-driver, Makefile.am, Makefile.in:
Autotools 1.12 changed the way tests are run during "make check"
so add a new "custom test driver" to run tests on Android, and
modify Makefile.am / Makefile.in accordingly. Otherwise,
'make check' tried to run the tests on the host.
- android/test-shell.sh:
Allow several tests to run in parallel on the device, by
creating a custom test directory for each test process.
This allows running "make check -j8" reliably.
- src/common/linux/file_id_unittest.cc:
Disable the SelfStrip test on Android, since it assumes a 'strip'
executable is available on the target system where the test runs.
BUG=NONE
R=mark@chromium.org, ted.mielczarek@gmail.com
TEST=android/run-checks.sh --ndk-dir=/path/to/android-ndk-r9b
Review URL: https://breakpad.appspot.com/904003
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1259 4c0a9323-5329-0410-9bdc-e9ce6186880e
The inconsistent and duplicated references to gDebugLog caused
problems building on iOS and the current logging implementation
had little utility because it was never activated in debug builds.
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1257 4c0a9323-5329-0410-9bdc-e9ce6186880e
Add a resetConfiguration method to BreakpadController for iOS. The new method
resets the controller configuration to its initial value, which is the
infoDictionary of the bundle of the application.
Patch by KiYun Roe <kiyun@chromium.org>
BUG=554
Review URL: https://breakpad.appspot.com/904002/
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1256 4c0a9323-5329-0410-9bdc-e9ce6186880e
There are a bunch of tests that use invalid memory acesses (on purpose)
to trigger a crash so that we can detect things are dumped correctly.
When we run under ASAN, it catches those accesses and the breaks the
testing flow.
For now, use the existing ADDRESS_SANITIZER symbol to disable more tests.
Ideally we'd use a compile-time attribute to disable ASAN on a few funcs,
but that seems to be broken atm.
BUG=chromium:293519
BUG=chromium:304575
TEST=ran unittests under ASAN and they now pass
TEST=ran unittests w/out asan/clang and they still pass
R=benchan@chromium.org
Review URL: https://breakpad.appspot.com/884002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1255 4c0a9323-5329-0410-9bdc-e9ce6186880e
If you try to process a file using a 32bit build that is larger than
2GiB in size, the linux kernel will reject things:
$ strace -eopen dump_syms ./chrome ./ > chrome.sym
...
open(".//chrome.debug", O_RDONLY) = -1 EOVERFLOW (Value too large for defined data type)
So let's use the existing autoconf macro to check for and enable support
as need be.
We have to shift the existing m32 logic up to before we start doing
feature test macros though otherwise a simple configure won't work:
$ ./configure --enable-m32
This is because it first tests LFS and such w/out the -m32 flags.
BUG=chromium:266064
TEST=`./configure --enable-m32 && make && make check` passes
R=benchan@chromium.org
Review URL: https://breakpad.appspot.com/619002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1250 4c0a9323-5329-0410-9bdc-e9ce6186880e
For CPUs that don't support the MMX instruction set, such pre-Pentium III or industrial x86 embedded PCs, the minidump fails when it tries to retrieve MMX specific registers.
This patch adds MMX detection for that call.
Tested on Ubuntu 12.04 with i686, and on a custom Linux distro on a Vortex86DX microcontroller.
Original review: https://breakpad.appspot.com/455002/
A=aras.vaichas
BUG=495
Review URL: https://breakpad.appspot.com/864002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1248 4c0a9323-5329-0410-9bdc-e9ce6186880e
It is incorrect to wrap close in HANDLE_EINTR on Linux.
Unnecessary #includes of eintr_wrapper.h are also removed. The variable naming
within the macro is also updated per Chromium r178174.
einter_wrapper.h contains a non-mechanical change. Mechanical changes were
generated by running:
sed -E -i '' \
-e 's/((=|if|return|CHECK|EXPECT|ASSERT).*)HANDLE(_EINTR\(.*close)/\1IGNORE\3/' \
-e 's/(ignore_result|void ?)\(HANDLE_EINTR\((.*close\(.*)\)\)/\2/' \
-e 's/(\(void\) ?)?HANDLE_EINTR\((.*close\(.*)\)/\2/' \
$(grep -rl HANDLE_EINTR.*close . --exclude-dir=.svn)
sed -E -i '' -e '/#include.*eintr_wrapper\.h"/d' \
$(grep -EL '(HANDLE|IGNORE)_EINTR' \
$(grep -Elr '#include.*eintr_wrapper\.h"' . --exclude-dir=.svn))
BUG=chromium:269623
R=ted.mielczarek@gmail.com
Review URL: https://breakpad.appspot.com/784002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1239 4c0a9323-5329-0410-9bdc-e9ce6186880e
The std::string dumpFilename already contains the full pathname to the dump file. Appending it to the dumpDirAsNSString creates a string with the path portion duplicated, e.g.:
/var/mobile/Applications/516BE756-DFD4-4F9B-85D5-85966B0038F7/Library/Caches/Breakpad/var/mobile/Applications/516BE756-DFD4-4F9B-85D5-85966B0038F7/Library/Caches/Breakpad/0A406D28-437D-48EE-9989-23F7F871818E.dmp
Instead of this:
/var/mobile/Applications/516BE756-DFD4-4F9B-85D5-85966B0038F7/Library/Caches/Breakpad/0A406D28-437D-48EE-9989-23F7F871818E.dmp
R=markus@chromium.org, qsr@chromium.org
Review URL: https://breakpad.appspot.com/744002
Patch from Akiva <scirsw@gmail.com>.
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1237 4c0a9323-5329-0410-9bdc-e9ce6186880e
Adds an ARM64-specific definition of MDRawContext and support for writing out a
minidump when running on ARM64. Additionally, extends the iOS minidump generator
for NSExceptions to work on ARM64 as well as ARM.
Patch by Colin Blundell <blundell@chromium.org>
BUG=542
Review URL: https://breakpad.appspot.com/664002/
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1235 4c0a9323-5329-0410-9bdc-e9ce6186880e
SIGABRT can be generated internally, usually by calling abort(),
or externally by another process. When the signal is generated
by the kernel, info->si_pid is 0 and the signal is treated in the
same way as an exception (SIGSEGV, etc.), but the assumption
that the exception happens again upon return from the handler
is wrong, so we must have a special case for this.
Original CL: https://breakpad.appspot.com/734002/
BUG=chromium:303075
TEST=tested with Alt-VolumeUp-X on Chrome OS
A=semenzato@chromium.orgR=semenzato@google.com
Review URL: https://breakpad.appspot.com/754002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1233 4c0a9323-5329-0410-9bdc-e9ce6186880e
.raSearchStart in the cases where there are alignment operators in
the program string.
If alignment operators are found in the program string, the current
value of %ebp must be valid and it is the only reliable data point
that can be used for getting to the previous frame. Previously, the
.raSearchStart calculation was based on %esp and when %esp is aligned
in the current frame (which is a lossy operation) the resulting
.raSearchStart cannot was incorrect. There is code that is trying to
work around this problem (scanning of up to 3 words for a return
address) which is unreliable and it doesn't work in many cases (e.g.
when the alignment is on a 64-byte boundary).
This fix is already deployed in Google and it was measured to reduce
the number of wrong stack traces (for Windows crashes) by 45%. No
regressions have been found so far.
Here is an example of an issue that was fixed by this change (where
register %esp is aligned on the 64-byte boundary and the workarounds
that we already had didn't work):
https://code.google.com/p/chromium/issues/detail?id=311359
0:013> uf chrome_59630000!base::MessagePumpForIO::DoRunLoop
518 59685c39 55 push ebp
518 59685c3a 8bec mov ebp,esp
518 59685c3c 83e4c0 and esp,0FFFFFFC0h <== 64-byte boundary
518 59685c3f 83ec34 sub esp,34h
518 59685c42 53 push ebx
518 59685c43 56 push esi
Program string contains 64-byte alignment:
$T1 .raSearch = $T0 $T1 4 - 64 @ = $ebp $T1 4 - ^ = $eip $T1 ^ =
$esp $T1 4 + = $20 $T0 56 - ^ = $23 $T0 60 - ^ = $24 $T0 64 - ^ =
Review URL: https://breakpad.appspot.com/694002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1232 4c0a9323-5329-0410-9bdc-e9ce6186880e
Apparently, as of the 10.8 SDK, Apple has quietly decided that the first
argument to NSLocalizedString is supposed to be usable as-is as a format
string, instead of simply being the key to obtain a usable format string.
The recent clang trunk enforces this, resulting in build breaks like
crash_report_sender.m:560:14: error: data argument not used by format string [-Werror,-Wformat-extra-args]
displayName];
^
Breaking the result of NSLocalizedString into a temporary NSString* is enough
to suppress the warning.
BUG=chromium:314109
R=thakis@chromium.org
Review URL: https://breakpad.appspot.com/674003
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1230 4c0a9323-5329-0410-9bdc-e9ce6186880e
In my testing, ARM V8 object files and ARM V8 slices of universal binaries do
not contain debug_frame sections (at least at this time), and hence dump_syms
does not output CFI for ARM V8 even in the absence of the "-c" flag.
Patch by:blundell@chromium.org
BUG=542
R=qsr@chromium.org
Review URL: https://breakpad.appspot.com/642002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1222 4c0a9323-5329-0410-9bdc-e9ce6186880e
This patch fixes the build for Android on MIPS when
using the latest official Android NDK (r9):
- Update src/common/android/include/elf.h to add a missing
definition for SHT_MIPS_DWARF.
- Add src/common/android/include/sgidefs.h required by LSS
when compiling for MIPS.
- Update android/run-checks.sh to work properly with
the --abi=mips option. All tests were passed succesfully
with an emulator system image running Android 4.2.
- Update other Android-specific files.
R=Petar.Jovanovic@imgtec.com, mark@chromium.org
Review URL: https://breakpad.appspot.com/633002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1216 4c0a9323-5329-0410-9bdc-e9ce6186880e
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
This patch improves several things for Linux/ARM:
- Better detection of the number of CPUs on the target
device. The content of /proc/cpuinfo only matches the
number of "online" CPUs, which varies over time with
recent Android devices.
- Reconstruct the CPUID and ELF hwcaps values from
/proc/cpuinfo, this is useful to better identify
target devices in minidumps.
- Make minidump_dump display the new information
in useful ways.
- Write a small helper class to parse /proc/cpuinfo
and also use it for x86/64.
- Write a small helper class to parse sysfds cpu lists.
- Add a my_memchr() implementation.
- Add unit tests.
Tested on a Nexus S (1 CPU), Galaxy Nexus (2 CPUs)
and a Nexus 4 (4 CPUs).
Review URL: https://breakpad.appspot.com/540003
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1160 4c0a9323-5329-0410-9bdc-e9ce6186880e
