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
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
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
Three unit tests were failing on recent ARM devices (e.g. Galaxy Nexus
or Nexus 4), while ran properly on older ones (e.g. Nexus S).
The main issue is that the instruction cache needs to be explicitely
cleared on ARM after writing machine code bytes to a malloc()-ed
page with PROT_EXEC.
Review URL: https://breakpad.appspot.com/540002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1132 4c0a9323-5329-0410-9bdc-e9ce6186880e
If the stack sizes for threads in the MinidumpSizeLimit test are too big,
then subtracting 64KB from the normal minidump file size is not enough to
trigger the size-limiting logic. Instead of basing the arbitrary limit off
of the normal file size, make it relative to the 8KB stack size the logic
assumes.
BUG=google-breakpad:510
TEST=Ran unittests
Review URL: https://breakpad.appspot.com/504002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1090 4c0a9323-5329-0410-9bdc-e9ce6186880e
When there are upwards of 200 threads in a crashing process, each having an
8KB stack, this can result in a huge, 1.8MB minidump file. So I added a
parameter that, if set, can compel the minidump writer to dump less stack.
More specifically, if the writer expects to go over the limit (due to the
number of threads), then it will dump less of a thread's stack after the
first 20 threads.
There are two ways to specify the limit, depending on how you write minidumps:
1) If you call WriteMinidump() directly, there's now a version of the
function that takes the minidump size limit as an argument.
2) If you use the ExceptionHandler class, the MinidumpDescriptor object you
pass to it now has a set_size_limit() method you would call before
passing it to the constructor.
BUG=chromium-os:31447, chromium:154546
TEST=Wrote a size-limit unittest; Ran unittests
Review URL: https://breakpad.appspot.com/487002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1082 4c0a9323-5329-0410-9bdc-e9ce6186880e
Breakpad can be used on processes where a mistaken
library saves then restores one of our signal handlers
with 'signal' instead of 'sigaction'.
This loses the SA_SIGINFO flag associated with the
Breakpad handler, and in some cases (e.g. Android/ARM
kernels), the values of the 'info' and 'uc' parameters
that ExceptionHandler::SignalHandler() receives will
be completely bogus, leading to a crash when the function
is executed (and of course, no minidump generation).
To work-around this, have SignalHandler() check the state
of the flag. If it is incorrectly unset, re-register with
'sigaction' and the correct flag, then return. The signal
will be re-thrown, and this time the function will be
called with the correct values.
Review URL: https://breakpad.appspot.com/481002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1067 4c0a9323-5329-0410-9bdc-e9ce6186880e
- One of the unit test binaries refused to link due to
missing linker flags.
- The WriteDSODebug() function now works on Android, so
do not special-case it anymore.
- Ensure android/run-checks.sh will complain properly if
the client unit test suite fails on Android. It used to
consider that such failures were acceptable. Note that
it still considers failures when running the tools and
processor test suite on the device normal (fixing this
is a lot harder, and these parts of Breakpad typically
never run on a device, but on the host).
Review URL: https://breakpad.appspot.com/482002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1066 4c0a9323-5329-0410-9bdc-e9ce6186880e
Currently, if a thread's stack pointer is not within a valid memory page,
the minidump writing will fail with an error. This change allows an invalid
stack pointer by simply setting the memory size to zero in the minidump.
The processing code already checks for the size being zero, although it
currently just gives an error (see https://breakpad.appspot.com/413002/).
BUG=google-breakpad:499, chromium-os:34880
TEST=make check, manually ran minidump-2-core and core2md
Review URL: https://breakpad.appspot.com/478002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1065 4c0a9323-5329-0410-9bdc-e9ce6186880e
