This allows for the getter to be used in IProtocol's destructor, and generally
brings IProtocol more in line with IToplevelProtocol.
Differential Revision: https://phabricator.services.mozilla.com/D32042
--HG--
extra : moz-landing-system : lando
Don't hold gMutex when calling HandleSharePortsMessage() from PortServerThread to avoid deadlock.
Differential Revision: https://phabricator.services.mozilla.com/D31694
--HG--
extra : moz-landing-system : lando
These values were only being used for assertions within IPDL send
methods. They had no positive impact beyond causing crashes when sending
a message over a dead actor.
Differential Revision: https://phabricator.services.mozilla.com/D30235
--HG--
extra : moz-landing-system : lando
Historically we've failed very loudly when receiving a message which was
destined for an actor which had already been destroyed. This had the
effect of requiring manual teardown for most actors, as work would need
to be done to ensure messages weren't sent when the target actor might
be about to tear itself down.
In addition, due to this teardown work being done outside of IPDL, this
work would have to manually be checked in subactors, and involved the
addition of new flags, such as `mIPCOpen`, in order to track whether IPC
had begun to be shut down, and discard messages manually if it had.
It is an ongoing issue that we occasionally miss places where we need to
discard messages, and it is easy to not remember to perform async
destruction when building a new actor, meaning that extra work is
required to correctly discard messages when the actor is being torn
down. Due to the correct decision, almost all of the time, being to
discard the message, this patch takes the approach of transforming the
crash which was previously performed into a message discard.
The hope is that this will reduce the burden on actor implementors, by
allowing the use of `Send__delete__` without first synchronizing with
the remote actor, as well as reduce unintentional crashes.
Differential Revision: https://phabricator.services.mozilla.com/D28892
--HG--
extra : moz-landing-system : lando
Upon a content process crash or hang crash annotations were incrementally
written into the .extra file starting with the exception handler callback and
then in a number of different places before the file was ready for submission.
This had a number of downsides: since the annotations were directly added to
the file it was impossible to tell which ones were already written at a
certain point in time, additionally some were written twice or even thrice.
The code doing the writing would also behave differently depending on the
contents of the file, the parameters passed to it and the contents of global
variables.
This change overhauls the whole process by keeping the annotations into a
temporary per-crash annotation table which is filled with all the required
annotations before being written out in a single pass when they are ready.
The annotations are gathered from the main process annotation table, the
per-process one (held by the CrashReporterHost) and exception-time specific
ones.
The resulting annotations are slightly different than before the patch: first
of all there are no more duplicate entries in the .extra file and secondly all
content/plugin process hangs annotations are properly filtered, before
annotations that were main process-only would leak into them.
Differential Revision: https://phabricator.services.mozilla.com/D31069
--HG--
extra : moz-landing-system : lando
This removes the XRE_TakeMinidumpForChild() which does not need to be
exposed anymore in the XUL API as well as
IToplevelProtocol::TakeMinidump() which was simply unused.
Differential Revision: https://phabricator.services.mozilla.com/D31062
--HG--
extra : moz-landing-system : lando
This patch changes the way how we handle sync ctor send errors. They are now
ignored and treated like messages which successfully were queued to send, but
got lost due to the other side hanging up.
For more details, see bug 1509362 which originally did it for async ctors.
The main differences here are that we destroy the actor and we return null when
the send fails.
Differential Revision: https://phabricator.services.mozilla.com/D31517
This isn't needed now that BrowserParent has the same name
as the protocol.
Differential Revision: https://phabricator.services.mozilla.com/D30151
--HG--
extra : rebase_source : dbfc1722a43e1f8fbbe01f1766a397b570fa7d6a
extra : source : 792b49f269bb6308e152290ed0dfa03efbffa536
extra : histedit_source : e001669549af547f5387a3b010ad52ebee6eea3f
ContentVerifier has been dead code since bug 1355166 (which, incidentally, means
it has no tests). Its presence is preventing improvements to
ContentSignatureVerifier (see e.g. bug 1534600), so this patch removes it.
As a result, the nsILoadInfo attributes verifySignedContent and enforceSRI are
also unused, so this patch removes those as well.
Differential Revision: https://phabricator.services.mozilla.com/D28885
--HG--
extra : moz-landing-system : lando
FileCreatorHelper creates a FileBlobImpl on the main-thread and, because of
this, we end up executing I/O operations on that thread, slowing down other
components. With this patch, FileCreatorHelper logic is moved to PBackground.
That the 'type' getter is still called on the main-thread because FileBlobImpl
uses nsIMIMEService which is a non thread-safe component.
Differential Revision: https://phabricator.services.mozilla.com/D27641
--HG--
extra : moz-landing-system : lando
FileCreatorHelper creates a FileBlobImpl on the main-thread and, because of
this, we end up executing I/O operations on that thread, slowing down other
components. With this patch, FileCreatorHelper logic is moved to PBackground.
That the 'type' getter is still called on the main-thread because FileBlobImpl
uses nsIMIMEService which is a non thread-safe component.
Differential Revision: https://phabricator.services.mozilla.com/D27641
--HG--
extra : moz-landing-system : lando
This consolidates array, maybe and unique ptrs in IPDL into a single
"has base type" qualifier, for types that wrap another type. I'm not
sure this patch fixes everything, but I think it is at least more
correct.
It also adds checking for the stuff inside the UniquePtr<>, because
the intent seems to be to allow things like protocol types in there.
Differential Revision: https://phabricator.services.mozilla.com/D28571
--HG--
extra : moz-landing-system : lando
Currently, when deserialization fails, the error message contains the base
name of the C++ type, without template parameters; this means we can get
unhelpfully vague errors about `RefPtr` or `Maybe` or `nsTArray`. (The
identical error cases are then merged by the compiler, so the execution
path can't be recovered from the crash dump.)
This patch uses the IPDL type instead. It would be possible to invoke
the code generator to use the full C++ type, but more complicated for no
real benefit.
Differential Revision: https://phabricator.services.mozilla.com/D28401
--HG--
extra : moz-landing-system : lando
Razvan Maries
Sylvestre Ledru
Nika Layzell
myfreeweb
Haik Aftandilian
Christoph Kerschbaumer
Gabriele Svelto
Jan Varga
Ryan Hunt
Bas Schouten
Mihai Alexandru Michis
Andrea Marchesini
Bogdan Tara
Cosmin Sabou
Aaron Klotz
Jonathan Kew
Dana Keeler
Honza Bambas
Brindusan Cristian
Andrew McCreight
Jed Davis