The handler is now capable of uploading crash reports from the database.
At present, only one upload attempt is made, and the report will be
moved to “completed” in the database after the attempt, regardless of
whether it succeeded or failed.
The handler also has support to push annotations from its command line
into the process annotations map of each crash report it writes. This is
intended to set basic information about each crash report, such as the
product ID and version. Each potentially crashy process can’t be relied
on to maintain this information on their own.
With this change, Crashpad is now 100% capable of running a handler that
maintains a database and uploads crash reports to a Breakpad-type server
such that Breakpad properly interprets the reports. This is all possible
from the command line.
TEST=run_with_crashpad --handler crashpad_handler \
-a --database=/tmp/crashpad_db \
-a --url=https://clients2.google.com/cr/staging_report \
-a --annotation=prod=crashpad \
-a --annotation=ver=0.6.0 \
crashy_program
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/982613002
ProcessSnapshotMinidump.
ModuleSnapshotMinidump is currently only capable of reading module
annotations, in both vector and simple-dictionary forms. It does not
read any other module information from minidump files. These annotations
are all that are necessary to be able to upload Crashpad-produced
minidumps to Breakpad crash processor servers, because Breakpad accepts
them as HTTP POST parameters, while Crashpad places them in the minidump
file itself.
TEST=snapshot_test ProcessSnapshotMinidump.Modules
BUG=crashpad:10
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/972383002
between classic and extension structures.
Previosly, each MinidumpModuleCrashpadInfo structure contained a
minidump_module_list_index field referencing a module in the
MINIDUMP_MODULE_LIST stream by index. This layout was discovered to
cause a problem for the new minidump reader in ModuleSnapshotMinidump.
Instead, the module list index for linkage should be contained in the
MinidumpModuleCrashpadInfoList alongside the LOCATION_DESCRIPTORs
pointing to each MinidumpModuleCrashpadInfo.
The organizational difference is small, but this enables a better design
for ModuleSnapshotMinidump. When initializing a ModuleSnapshotMinidump
with the new layout, it is possible for the caller to have access to the
location descriptor for the MinidumpModuleCrashpadInfo corresponding to
a MINIDUMP_MODULE_LIST. Previously, the caller would not have had this
data without interpreting each MinidumpModuleCrashpadInfo, which
ModuleSnapshotMinidump would have to do anyway.
MinidumpModuleCrashpadInfoListWriter was the only user of
MinidumpLocationDescriptorListWriter, which is obsoleted and removed in
this change. Its functionality is moving directly into
MinidumpModuleCrashpadInfoListWriter, but it is no longer generic enough
to maintain as a distinct class.
TEST=minidump_test \
MinidumpModuleCrashpadInfoWriter.*,MinidumpCrashpadInfoWriter.*
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/978463003
the Snapshot family.
For the time being, only ProcessSnapshotMinidump::AnnotationsSimpleMap()
is implemented. In order to complete the initial uploader for Crashpad,
ModuleSnapshotMinidump::AnnotationsSimpleMap() is also needed, to be
accessed by ProcessSnapshotMinidump::Modules().
TEST=snapshot_test ProcessSnapshotMinidump.*
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/932153003
implement the new interface.
The upcoming minidump reader will get minidump data from a
FileReaderInterface. For ease of testing, a string-based implementation
is provided. There wasn’t a good reason to have a separate
StringFileReader and StringFileWriter, so I combined them into a single
StringFile.
TEST=util_test StringFile.*
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/936153002
Some annotations will exist at a broader scope than per-module, which is
the only place that annotations can currently be stored. The product
name and version are not under the control of any module, but are
established when the first Crashpad client establishes a handler. These
annotations will be stored in a minidump’s MinidumpCrashpadInfo
structure, which applies to the entire minidump.
Within the snapshot interface, this data is carried within the
“process” snapshot because it is the top-level structure in that family.
Note that the data may not correspond directly with a process, however.
TEST=minidump_test MinidumpCrashpadInfoWriter.*
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/924673003
Upload isn’t actually hooked up yet, but this establishes the upload
thread and provides all of the plumbing to process pending reports. For
the time being, SkipReportUpload() is called for all pending reports.
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/918743002
As there are no extended file attributes available on all Windows file
systems (NTFS supports alternate data streams, but Chrome still supports
running on FAT), instead of using metadata attached to the file, metadata
is stored separately in a simple record-based file and keyed by UUID.
Initially, I attempted a metadata file beside each report, each locked
separately more closely mirroring the Mac implementation. But given the
expected number of of active reports (in the 10s to 100s range?) and the
size of the metadata for each, simply storing it all in one file is much
less complicated when considering error situations.
If the serialization/deserialization becomes a measurable problem, it
could be optimized at some complexity by reading/writing only as
necessary, or optimizing the storage.
R=mark@chromium.org, rsesek@chromium.org
BUG=crashpad:1
Review URL: https://codereview.chromium.org/867363003
The PUSH/POP are less noisy for sure. SUPPRESS is a little more
subtle -- it's correctly documented as "for this line and the next"
but that doesn't work well with our coding style.
R=mark@chromium.org
BUG=crashpad:1
Review URL: https://codereview.chromium.org/898133002
external defined symbols.
Indirect symbols remain unsupported.
Xcode 5.1 ld64-236.3/src/ld/LinkEditClassic.hpp
ld::tool::SymbolTableAtom<>::addGlobal() is responsible for producing
symbols found in the extdef portion of the symbol table. It always sets
the type to N_ABS, N_SECT, or N_INDR, each with the N_EXT bit set. The
N_PEXT bit is never set for non-object files, and we’re not concerned
with reading object files. With this change to tolerate N_INDR, I think
we’re covering all of the symbol types that we might find ld writing to
the extdef portion of the symbol table.
https://groups.google.com/a/chromium.org/forum/#!topic/crashpad-dev/k7QkLwO71ZoR=rsesek@chromium.org
Review URL: https://codereview.chromium.org/901463004
- Stack object instantiated for sizeof to avoid
d:\src\crashpad\crashpad\minidump\minidump_system_info_writer_test.cc(43) : error C2597: illegal reference to non-static member '_MINIDUMP_STRING::Buffer'
Could also just be sizeof(WCHAR) if that feels less ugly.
- narrowing cast
- potentially uninitialize variable warning
R=mark@chromium.org
BUG=crashpad:1
Review URL: https://codereview.chromium.org/886143004
MINIDUMP_MISC_INFO and MINIDUMP_MISC_INFO_2, etc. are not
derived from each other in Windows' dbghelp.h, so need
a reinterpret_cast.
arraysize fails on Struct::Member with a big mess (below)
but works ok on a local stack instance.
d:\src\crashpad\crashpad\minidump\minidump_misc_info_writer_test.cc(405) : error C2664: 'std::basic_string<char,std::char_traits<char>,std::allocator<char>>::basic_string(std::initializer_list<_Elem>,const std::allocator<char> &)' : cannot convert argument 1 from 'char' to 'const std::basic_string<char,std::char_traits<char>,std::allocator<char>> &'
with
[
_Elem=char
]
Reason: cannot convert from 'char' to 'const std::basic_string<char,std::char_traits<char>,std::allocator<char>>'
No constructor could take the source type, or constructor overload resolution was ambiguous
d:\src\crashpad\crashpad\minidump\minidump_misc_info_writer_test.cc(408) : error C2784: 'char (&ArraySizeHelper(const T (&)[N]))[N]' : could not deduce template argument for 'const T (&)[N]' from 'unknown'
d:\src\crashpad\crashpad\third_party\mini_chromium\mini_chromium\base\basictypes.h(39) : see declaration of 'ArraySizeHelper'
R=mark@chromium.org
BUG=crashpad:1
Review URL: https://codereview.chromium.org/899163004
test_process_snapshot.h apparently requires the full inclusion,
not a forward declaration otherwise it claims to be deleting
undefined types.
And, some more potentially uninitialized variables.
R=mark@chromium.org
BUG=crashpad:1
Review URL: https://codereview.chromium.org/902803002
Needed on Windows for sys/time.h.
d:\src\crashpad\crashpad\snapshot\test\test_process_snapshot.h(19) : fatal error C1083: Cannot open include file:
'sys/time.h': No such file or directory
R=mark@chromium.org
BUG=crashpad:1
Review URL: https://codereview.chromium.org/897973003
Had to move this one out to a scoped_ptr too, otherwise when
it's instantiated in test code on the stack,
d:\src\crashpad\crashpad\minidump\minidump_simple_string_dictionary_writer_test.cc(45) : warning C4815: 'dictionary_writer' : zero-sized array in stack object will have no elements (unless the object is an aggregate that has been aggregate initialized)
R=mark@chromium.org
BUG=crashpad:1
Review URL: https://codereview.chromium.org/895313004
A (somewhat cursory) inspection leads me to believe that there's
no particular alignment requirements for this object at this location,
so this warning can be ignored.
d:\src\crashpad\crashpad\minidump\minidump_context_writer.cc(43) : error C2220: warning treated as error - no 'object' file generated
d:\src\crashpad\crashpad\minidump\minidump_context_writer.cc(43) : warning C4316: 'crashpad::MinidumpContextAMD64Writer' : object allocated on the heap may not be aligned 16
R=mark@chromium.org
BUG=crashpad:1
Review URL: https://codereview.chromium.org/893393002
- dbghelp.h requires windows.h to be included before it (ick!).
Add a stub one for non_win to make this work.
- convert __attribute__ -> macro that can work work with MSVC;
- a handful of narrowing casts.
R=mark@chromium.org
BUG=crashpad:1
Review URL: https://codereview.chromium.org/883773005
deals solely with a weak FileHandle.
CrashReportDatabase::PrepareNewCrashReport() provides its caller with
both a FileHandle and a FilePath. While it’s possible to create a
FileWriter from the FilePath, it’s not necessary to have two FileHandles
open to the same file. Also, there’s no FileWriteMode::kReuseOrFail
option because it didn’t seem necessary[1], and although it would
actually be the most desirable option for a FileWriter here, allowing
the FileHandle to be used directly without reopening the file sidesteps
the problem entirely.
FileWriter is adapted to use WeakFileHandleFileWriter to minimize
duplication.
[1] https://codereview.chromium.org/818433002/diff/80001/util/file/file_io.h#newcode138R=rsesek@chromium.org, scottmg@chromium.org
Review URL: https://codereview.chromium.org/871193010
A crash handler needs a way to clean up after itself it it calls
CrashReportDatabase::PrepareCrashReport() to begin writing a new crash
report, but then encounters an error that renders the crash report
unusable. The new ErrorWritingCrashReport() method allows it to
communicate to the database that a previously-prepared crash report
should be removed without ever being promoted to a completed report
pending upload.
TEST=client_test CrashReportDatabaseTest.ErrorWritingCrashReport
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/904533002
- Various "FD" to "Handle"
- Existing Multiprocess implementation moves to _posix.
- Stub implementation for _win.
At the moment, multiprocess_exec_win.cc contains implementations of both
Multiprocess methods and MultiprocessExec functions. This will need more
work in the future, but reflects the idea that all tests should be in
terms of MultiprocessExec eventually.
Currently, this works sufficiently to have util_test succeed (including
multiprocess_exec_test, and the recently ported HTTPTransport tests.)
R=mark@chromium.org
BUG=crashpad:1, crashpad:7
Review URL: https://codereview.chromium.org/880763002
- Dependency on compat required for sys/types.h inclusion for ssize_t.
- Test impl of stat to avoid #error
- FileHandle isn't int on Windows.
client_test no longer links though, as it's still lacking an
implementation of CrashReportDatabase of course.
R=rsesek@chromium.org
BUG=crashpad:1
Review URL: https://codereview.chromium.org/875043004
off_t exists on Windows, but Seek is implemented in terms of
SetFilePointerEx which expects a LONGLONG, so FileOffset is LONGLONG.
So, use FileOffset in the test code so that it wraps at the expected
value.
R=mark@chromium.org
BUG=crashpad:1
Review URL: https://codereview.chromium.org/854883002
