This patch changes the crashreporter client code as well as the crash service
code to compute a SHA256 hash of a crash' minidump file and add it to the
crash ping. The crash service code computes the hash on the fly before handing
over the crash to the crash manager; the crash manager will then add it to the
crash ping. The crashreporter client on the other hand sends the hash via the
ping it generates but it also adds it to the event file so that the crash
manager can pick it up and send it along with its own crash ping. On Fennec
the crashreporter activity takes care of computing the hash.
SHA256 hash computation uses nsICryptoHash in the crash service, the
java.security.MessageDigest class in Fennec, the bundled NSS library in the
crashreporter when running on Windows and Mac and the system-provided NSS
library under Linux. The latter is required because the crashreporter client
uses the system curl library which is linked to NSS and which would thus clash
with the bundled one if used together.
This patch introduces two new methods for the nsICrashService interface:
|getMinidumpForID()| and |getExtraFileForID()|, these reliably retrieve the
.dmp and .extra files associated with a crash and ensure the files exist
before returning. These new methods are used in the CrashService for
processing and will become the only way to reliably retrieve those files
from a crash ID.
MozReview-Commit-ID: 8BKvqj6URcO
--HG--
extra : source : a4d8291c56fcde00238ab3166bbe6af6dd602340
This is a bug from https://hg.mozilla.org/mozilla-central/rev/2d171d75b746 (bug 1157546). It took a shortcut in trying to get around one of the downsides of tracking visibility on frames instead of content nodes.
We cannot get our primary frame during FrameCreate calls because FrameCreate is called during the frame's Init() function, which happens before the primary frame pointer is set.
So when TrackImage is called from FrameCreate |frame| will be null but mFrameCreateCalled will be true. So we won't hit the early return that tries to detect nonvisible images.
The comment being removed is just wrong. We can obtain a frame for <feImage> just as well as any other image type.
The thing that is different about <feImage> is that it calls IncApproximateVisibleCount() followed by FrameCreated() in the frame's Init() function. This means that the frame is marked visible at the time of the FrameCreated, and there will be no further calls to TrackImage (because there are no further changes). So the FrameCreated call is the last chance to mark this image visible. The regressing changeset tries to get around this by just considering the image visible whenever we know a frame exists (because of mFrameCreateCalled) but can't access it. This ends up affecting all types of images, not just <feImage>.
The above paragraph is also true for SVG <image> that are non-display.
This change moves us away from NSPR primitives for our primary
synchronization primitives. We're still using PRMonitor for
ReentrantMonitor, however.
The benefits of this change:
* Slightly faster, as we don't have to deal with some of NSPR's overhead;
* Smaller datatypes. On POSIX platforms in particular, PRLock is
enormous. PRCondVar also has some unnecessary overhead.
* Less dynamic memory allocation. Out of necessity, Mutex and CondVar
allocated the NSPR data structures they needed, which lead to
unnecessary checks for failure.
While sizeof(Mutex) and sizeof(CondVar) may get bigger, since they're
embedding structures now, the total memory usage should be less.
* Less NSPR usage. This shouldn't need any explanation.
Gabriele Svelto
Jonathan Watt
Sebastian Hengst
Jan de Mooij
Christoph Kerschbaumer
Stanford Lockhart
Timothy Nikkel
Shu-yu Guo
David Anderson
Emanuel Hoogeveen
Junior Hsu
srivatsav
John Dai
Glenn Randers-Pehrson
Edmund Wong
Wes Kocher
Steve Fink
Xidorn Quan
Geoff Brown
Carsten "Tomcat" Book
ffxbld
Nathan Froyd
Michael Layzell