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
