8 Commits

Author SHA1 Message Date
Mark Mentovai
6278690abe Update copyright boilerplate, 2022 edition (Crashpad)
sed -i '' -E -e 's/Copyright (.+) The Crashpad Authors\. All rights reserved\.$/Copyright \1 The Crashpad Authors/' $(git grep -El 'Copyright (.+) The Crashpad Authors\. All rights reserved\.$')

Bug: chromium:1098010
Change-Id: I8d6138469ddbe3d281a5d83f64cf918ec2491611
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3878262
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
2022-09-06 23:54:07 +00:00
Daniel Cheng
0affe61689 Migrate base::{size,empty,data} to STL equivalents in crashpad.
Bug: chromium:1299695
Change-Id: I95187a425b08c96430c659f843c379d506972f0f
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3496462
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
2022-03-01 12:06:49 +00:00
Lei Zhang
d8f60c8112 Swap from base/stl_util.h to cxx17_backports.h.
Chromium moved base::size() to base/cxx17_backports.h, so do the same in
mini_chromium and update the users in Crashpad.

Roll mini_chromium to 2f06f83f to make the new base header available.

Bug: chromium:1210983
Change-Id: Ie3dc4c189dcdfcac030b95fe285f94abb29a27bf
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/2917779
Commit-Queue: Lei Zhang <thestig@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
2021-05-25 21:44:52 +00:00
Mark Mentovai
cc166d71f4 Use base::size where appropriate, and ArraySize elsewhere
This is a follow-up to c8a016b99d97, following the post-landing
discussion at
https://chromium-review.googlesource.com/c/crashpad/crashpad/+/1393921/5#message-2058541d8c4505d20a990ab7734cd758e437a5f7

base::size, and std::size that will eventually replace it when C++17 is
assured, does not allow the size of non-static data members to be taken
in constant expression context. The remaining uses of ArraySize are in:

minidump/minidump_exception_writer.cc (×1)
minidump/minidump_system_info_writer.cc (×2, also uses base::size)
snapshot/cpu_context.cc (×4, also uses base::size)
util/misc/arraysize_test.cc (×10, of course)

The first of these occurs when initializing a constexpr variable. All
others are in expressions used with static_assert.

Includes:
Update mini_chromium to 737433ebade4d446643c6c07daae02a67e8deccao

f701716d9546 Add Windows ARM64 build target to mini_chromium
87a95a3d6ac2 Remove the arraysize macro
1f7255ead1f7 Placate MSVC in areas of base::size usage
737433ebade4 Add cast

Bug: chromium:837308
Change-Id: I6a5162654461b1bdd9b7b6864d0d71a734bcde19
Reviewed-on: https://chromium-review.googlesource.com/c/1396108
Commit-Queue: Mark Mentovai <mark@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
2019-01-04 22:42:57 +00:00
Avi Drissman
c8a016b99d Remove base's arraysize from Crashpad.
BUG=837308
R=mark@chromium.org

Change-Id: Ibecbfc7bc2d61ee54bc1114e4b20978adbc77db2
Reviewed-on: https://chromium-review.googlesource.com/c/1393921
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Avi Drissman <avi@chromium.org>
2019-01-03 19:44:15 +00:00
Mark Mentovai
1abaf22e28 Use readdir() instead of readdir_r() on all (POSIX) platforms
readdir_r() is a thread-safe version of readdir(), although readdir() is
not particularly thread-unsafe with most usage. The dirent* returned by
readdir() can only be invalidated by a subsequent readdir() or
closedir() on the same DIR*. In typical usage, where a returned dirent*
is used exclusively within a loop around readdir() and is not expected
to outlive that loop, there are no lifetime or thread-safety issues with
the use of readdir().

readdir_r() may be harmful in certain situations because its buffer is
not explicitly sized, and attempts to provide a suitably sized buffer
dynamically (which, incidentally, our code did not do) are subject to a
race condition.

https://elliotth.blogspot.com/2012/10/how-not-to-use-readdirr3.html
https://womble.decadent.org.uk/readdir_r-advisory.html

glibc has already deprecated readdir_r(), and all Linux (including
Android) code was already using readdir(). This change eliminates
variant codepaths. It delegates buffer sizing (which we weren’t doing
correctly) to the C library, which also has more options at its disposal
to avoid races in sizing that buffer.

Change-Id: I4fca8948454116360180ad0017f226d06727ef81
Reviewed-on: https://chromium-review.googlesource.com/705756
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
2017-10-06 21:08:50 +00:00
Mark Mentovai
7e6a0145b1 mac handler: Record the number of open files in the handler process
The "file-limit" annotation has shown that the system as a whole is not
likely to be out of file descriptors globally. It’s possible that a file
descriptor leak in crashpad_handler itself is responsible for certain
crashes. Add a count of the number of open files in the handler process
to this annotation to test this theory.

Bug: crashpad:180
Change-Id: If6f2304fdabddd29636ba4ac5a7d1e0fff7f4b61
Reviewed-on: https://chromium-review.googlesource.com/585852
Reviewed-by: Robert Sesek <rsesek@chromium.org>
2017-07-26 17:21:45 +00:00
Mark Mentovai
b8aaa22905 mac handler: Record a file-limits annotation (temporarily)
The "file-limit" annotation will be used to confirm the theory that
certain crashes are caused by systems at or near their file descriptor
table size limits.

The annotation records the system-wide kern.num_files and kern.maxfiles
values, and the process-specific current and maximum file descriptor
limits.

The annotation will be set on crashpad_handler startup, and will be
refreshed every time an exception is handled and every time the upload
thread processes a pending report.

It’s expected that this annotation will be removed after enough data has
been collected to confirm the theory. However, the principle is useful
enough that we may want to provide this feature more generally under
bugs 19 or 21.

Bug: crashpad:180
Change-Id: I3bb78fae60e0567bc4ac2625716e0abe0ddae08c
Reviewed-on: https://chromium-review.googlesource.com/479914
Reviewed-by: Robert Sesek <rsesek@chromium.org>
2017-04-18 17:27:31 +00:00