This patch does a couple of things:
* I added a new class, |WindowsError| to WinHeaderOnlyUtils. The idea here is
to encapsulate as much of the Windows error gamut as possible into one class.
Since Win32 errors and NTSTATUS codes may both be encoded as HRESULTs, I
used the latter type to store the error. It also contains functions for
converting between the various error code formats, as well as stringification
via FormatMessage.
* I added |LauncherError| which also includes file and line number information,
which I believe will be important for launcher process failure diagnostics.
(Instantiation of LauncherErrors obviously must be done via macros to capture
__FILE__ and __LINE__).
* I then converted all of the launcher process code (and its few depenencies) to
utilize this new functionality via the new |LauncherResult| type.
* If we detect an error in one of the top-level launcher process functions, we
pass it to |HandleLauncherError| for processing. This function currently just
throws up a |MessageBox| like the previous code did, with the intention of
enhancing that further in the future.
Differential Revision: https://phabricator.services.mozilla.com/D12365
--HG--
extra : moz-landing-system : lando
This patch does a couple of things:
* I added a new class, |WindowsError| to WinHeaderOnlyUtils. The idea here is
to encapsulate as much of the Windows error gamut as possible into one class.
Since Win32 errors and NTSTATUS codes may both be encoded as HRESULTs, I
used the latter type to store the error. It also contains functions for
converting between the various error code formats, as well as stringification
via FormatMessage.
* I added |LauncherError| which also includes file and line number information,
which I believe will be important for launcher process failure diagnostics.
(Instantiation of LauncherErrors obviously must be done via macros to capture
__FILE__ and __LINE__).
* I then converted all of the launcher process code (and its few depenencies) to
utilize this new functionality via the new |LauncherResult| type.
* If we detect an error in one of the top-level launcher process functions, we
pass it to |HandleLauncherError| for processing. This function currently just
throws up a |MessageBox| like the previous code did, with the intention of
enhancing that further in the future.
Differential Revision: https://phabricator.services.mozilla.com/D12365
--HG--
extra : moz-landing-system : lando
This patch does a couple of things:
* I added a new class, |WindowsError| to WinHeaderOnlyUtils. The idea here is
to encapsulate as much of the Windows error gamut as possible into one class.
Since Win32 errors and NTSTATUS codes may both be encoded as HRESULTs, I
used the latter type to store the error. It also contains functions for
converting between the various error code formats, as well as stringification
via FormatMessage.
* I added |LauncherError| which also includes file and line number information,
which I believe will be important for launcher process failure diagnostics.
(Instantiation of LauncherErrors obviously must be done via macros to capture
__FILE__ and __LINE__).
* I then converted all of the launcher process code (and its few depenencies) to
utilize this new functionality via the new |LauncherResult| type.
* If we detect an error in one of the top-level launcher process functions, we
pass it to |HandleLauncherError| for processing. This function currently just
throws up a |MessageBox| like the previous code did, with the intention of
enhancing that further in the future.
Differential Revision: https://phabricator.services.mozilla.com/D12365
--HG--
extra : moz-landing-system : lando
This patch does a couple of things:
* I added a new class, |WindowsError| to WinHeaderOnlyUtils. The idea here is
to encapsulate as much of the Windows error gamut as possible into one class.
Since Win32 errors and NTSTATUS codes may both be encoded as HRESULTs, I
used the latter type to store the error. It also contains functions for
converting between the various error code formats, as well as stringification
via FormatMessage.
* I added |LauncherError| which also includes file and line number information,
which I believe will be important for launcher process failure diagnostics.
(Instantiation of LauncherErrors obviously must be done via macros to capture
__FILE__ and __LINE__).
* I then converted all of the launcher process code (and its few depenencies) to
utilize this new functionality via the new |LauncherResult| type.
* If we detect an error in one of the top-level launcher process functions, we
pass it to |HandleLauncherError| for processing. This function currently just
throws up a |MessageBox| like the previous code did, with the intention of
enhancing that further in the future.
Differential Revision: https://phabricator.services.mozilla.com/D12365
--HG--
extra : moz-landing-system : lando
JSONWriter currently calls new and delete indirectly through mozilla::MakeUnique to allocate a buffer. Becuase of this, the methods of this class cannot be invoked within Spidermonkey due to https://searchfox.org/mozilla-central/source/config/check_vanilla_allocations.py#6-14. Therefore, JSONWriter needs an AllocPolicy template parameter so that the allocation and deallocation routines can be changed to match the JS AllocPolicy when invoked within SpiderMonkey.
Differential Revision: https://phabricator.services.mozilla.com/D7279
--HG--
extra : moz-landing-system : lando
This change applies to Windows only.
Firefox will need to migrate the directory from the old location to the new location. This will be done only once by setting the pref `app.update.migrated.updateDir2.<install path hash>` to `true` once migration has completed.
Note: The pref name app.update.migrated.updateDir has already been used, thus the '2' suffix. It can be found in ESR24.
This also removes the old handling fallback for generating the update directory path. Since xulrunner is no longer supported, this should no longer be needed. If neither the vendor nor app name are defined, it falls back to the literal string "Mozilla".
The code to generate the update directory path and the installation hash have been moved to the updatecommon library. This will allow those functions to be used in Firefox, the Mozilla Maintenance Service, the Mozilla Maintenance Service Installer, and TestAUSHelper.
Additionally, the function that generates the update directory path now has extra functionality. It creates the update directory, sets the permissions on it and, optionally, recursively sets the permissions on everything within.
This patch adds functionality that allows Firefox to set permissions on the new update directory on write failure. It attempts to set the permissions itself and, if that fails and the maintenance service is enabled, it calls into the maintenance service to try from there. If a write fails and the permissions cannot be fixed, the user is prompted to reinstall.
Differential Revision: https://phabricator.services.mozilla.com/D4249
--HG--
rename : toolkit/mozapps/update/updater/win_dirent.cpp => toolkit/mozapps/update/common/win_dirent.cpp
rename : toolkit/mozapps/update/tests/unit_aus_update/cleanupSuccessLogMove.js => toolkit/mozapps/update/tests/unit_aus_update/updateDirectoryMigrate.js
extra : moz-landing-system : lando
This patch adds the definitions of the RefPtr constructor and operator=.
It also refactors some stuff in AgileReference to make these objects easier
to use. Since it's just a bunch of C++ goop, I figured that you'd be fine to
review this. Let me know if you want to add a reviewer who is more familiar
with the COM nuances.
Depends on D5317
Differential Revision: https://phabricator.services.mozilla.com/D5318
--HG--
extra : moz-landing-system : lando
This patch adds the definitions of the RefPtr constructor and operator=.
It also refactors some stuff in AgileReference to make these objects easier
to use. Since it's just a bunch of C++ goop, I figured that you'd be fine to
review this. Let me know if you want to add a reviewer who is more familiar
with the COM nuances.
Depends on D5317
Differential Revision: https://phabricator.services.mozilla.com/D5318
--HG--
extra : source : 62b404e59c325af23d9133a5e18cc7cc477cafdd
This patch adds the definitions of the RefPtr constructor and operator=.
It also refactors some stuff in AgileReference to make these objects easier
to use. Since it's just a bunch of C++ goop, I figured that you'd be fine to
review this. Let me know if you want to add a reviewer who is more familiar
with the COM nuances.
Depends on D5317
Differential Revision: https://phabricator.services.mozilla.com/D5318
--HG--
extra : moz-landing-system : lando
This patch adds the definitions of the RefPtr constructor and operator=.
It also refactors some stuff in AgileReference to make these objects easier
to use. Since it's just a bunch of C++ goop, I figured that you'd be fine to
review this. Let me know if you want to add a reviewer who is more familiar
with the COM nuances.
Depends on D5317
Differential Revision: https://phabricator.services.mozilla.com/D5318
--HG--
extra : moz-landing-system : lando
Doing std::move when returning/assigning a local or temporary object is
preventing the compiler from performing copy elision.
Differential Revision: https://phabricator.services.mozilla.com/D5019
--HG--
extra : moz-landing-system : lando
Doing std::move when returning/assigning a local or temporary object is
preventing the compiler from performing copy elision.
In the case of UniquePtr, it's easier to `return MakeUnique<T>(...)` instead of
the move verbose `UniquePtr<T> r(new T(...)); return r;`
Differential Revision: https://phabricator.services.mozilla.com/D5019
--HG--
extra : moz-landing-system : lando
This introduces the machinery needed to generate crash annotations from a YAML
file. The relevant C++ functions are updated to take a typed enum. JavaScript
calls are unaffected but they will throw if the string argument does not
correspond to one of the known entries in the C++ enum. The existing whitelists
and blacklists of annotations are also generated from the YAML file and all
duplicate code related to them has been consolidated. Once written out to the
.extra file the annotations are converted in string form and are no different
than the existing ones.
All existing annotations have been included in the list (and some obsolete ones
have been removed) and all call sites have been updated including tests where
appropriate.
--HG--
extra : source : 4f6c43f2830701ec5552e08e3f1b06fe6d045860
This introduces the machinery needed to generate crash annotations from a YAML
file. The relevant functions are updated to take a typed enum (in C++) and an
integer constant (in JavaScript). A JavaScript wrapper around the crash
reporter service is provided to hold the constants. The existing whitelists
and blacklists of annotations are also generated from the YAML file and the
existing duplicate code has been consolidated. Once written out to the .extra
file the annotations are converted in string form and are no different than
the existing ones.
All existing annotations have been included (and some obsolete ones removed)
and all call sites have been updated including tests.
--HG--
extra : rebase_source : b4f0d4bf83c64851028c271d3fab3ebcb6fbcd3e
This introduces the machinery needed to generate crash annotations from a YAML
file. The relevant functions are updated to take a typed enum (in C++) and an
integer constant (in JavaScript). A JavaScript wrapper around the crash
reporter service is provided to hold the constants. The existing whitelists
and blacklists of annotations are also generated from the YAML file and the
existing duplicate code has been consolidated. Once written out to the .extra
file the annotations are converted in string form and are no different than
the existing ones.
All existing annotations have been included (and some obsolete ones removed)
and all call sites have been updated including tests.
--HG--
extra : rebase_source : f0e8d229581ac5c0daa0e0454cb258746108e28d
PublishTarget calls Unlock on our LiveSetAutolock.
It's possible for GetInitialInterceptorForIID to fail after this point.
This will cause the failure cleanup code to run, which tries to call Unlock again.
However, the previous call to Unlock set mLiveSet to null, and Unlock previously didn't handle this case.
Now, unlock is a no-op (in release builds) if it's already been called.
MozReview-Commit-ID: 15ffXR6nKqc
--HG--
extra : rebase_source : bf072824f15f5574dd8afbedef82b795086d5fff
If GetInitialInterceptorForIID fails, the live set lock is not released in most cases, but the newly created Interceptor will be destroyed.
The Interceptor's destructor tries to acquire the live set lock again, but that causes a deadlock, since reentry is no longer allowed for a mutex after bug 1364624.
GetInitialInterceptorForIID now ensures the live set lock is always released on failure, thus preventing the deadlock.
MozReview-Commit-ID: z0Q7JLnJXQ
--HG--
extra : amend_source : 0b9837e5500754b5782e72337fc59b7904c5e29c
Fairly straightforward, just a blanket removal. Haven't heard
anything on dev-platform or fx-data-dev regarding this removal,
so I think it's likely safe to remove on Nightly, and we can
revert if anyone makes a fuss.
As part of removing the HangMonitor, I renamed a few things and
reorganized the namespaces to not depend on a HangMonitor
namespace. Hopefully this doesn't produce too much noise in the
diff, it just seemed appropriate to move everything around
rather than keep dangling vestiges of the old system.
MozReview-Commit-ID: 8C8NFnOP5GU
--HG--
extra : rebase_source : dd000a05bfc2da40c586644d33ca4508fa5330f6
Fairly straightforward, just a blanket removal. Haven't heard
anything on dev-platform or fx-data-dev regarding this removal,
so I think it's likely safe to remove on Nightly, and we can
revert if anyone makes a fuss.
As part of removing the HangMonitor, I renamed a few things and
reorganized the namespaces to not depend on a HangMonitor
namespace. Hopefully this doesn't produce too much noise in the
diff, it just seemed appropriate to move everything around
rather than keep dangling vestiges of the old system.
MozReview-Commit-ID: 8C8NFnOP5GU
--HG--
extra : rebase_source : 59e4a6ced7d14d2a01c0b79e944078ea84cae523
Same approach as the other bug, mostly replacing automatically by removing
'using mozilla::Forward;' and then:
s/mozilla::Forward/std::forward/
s/Forward</std::forward</
The only file that required manual fixup was TestTreeTraversal.cpp, which had
a class called TestNodeForward with template parameters :)
MozReview-Commit-ID: A88qFG5AccP
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
Fairly straightforward, just a blanket removal. Haven't heard
anything on dev-platform or fx-data-dev regarding this removal,
so I think it's likely safe to remove on Nightly, and we can
revert if anyone makes a fuss.
As part of removing the HangMonitor, I renamed a few things and
reorganized the namespaces to not depend on a HangMonitor
namespace. Hopefully this doesn't produce too much noise in the
diff, it just seemed appropriate to move everything around
rather than keep dangling vestiges of the old system.
MozReview-Commit-ID: 8C8NFnOP5GU
--HG--
extra : rebase_source : a8840bd26f4b01b756ffa72345ababb625048550
We want to spin for faster response, but we only want to spin for a very short time.
If we're waiting for a while, we don't want to be burning CPU for the entire time.
Therefore, only spin for 30 ms, then fall back to waiting on an event.
MozReview-Commit-ID: ErAIwpsIqYz
--HG--
extra : rebase_source : b6ac024adb7853456fd06c4385cf32184c8aeca2
I missed this one in bug 1431404.
This condition is rare and does indicate a problem which breaks accessibility.
However, we aren't getting any closer to diagnosing this as a result of this crash, so it causes user pain without any gain to us.
MozReview-Commit-ID: GncQGeZckrV
--HG--
extra : rebase_source : b6670005d53bc6d0009f0b8b142c2ab837b7d2e7
Because Interceptors disable COM garbage collection to improve performance, they never receive Release calls from remote clients.
If the object can be shut down while clients still hold a reference, this function can be used to force COM to disconnect all remote connections (using CoDisconnectObject) and thus release the associated references to the Interceptor, its target and any objects associated with the HandlerProvider.
A HandlerProvider::DisconnectHandlerRemotes method also had to be added to allow HandlerProviders to disconnect clients for their own objects.
MozReview-Commit-ID: JaxEkOtrP1M
--HG--
extra : rebase_source : bc7a4ab79458eaaddcef8df74ff4d6f685fbfdce
extra : histedit_source : 087f17f09a0c0e1c8e3b5f6d9690f331c15f0b95
COM queries for special interfaces such as IFastRundown when creating a marshaler.
We don't want these being dispatched to the main thread, since this would cause a deadlock on mStdMarshalMutex if the main thread is also querying for IMarshal.
MozReview-Commit-ID: EQcN8Zhewjh
--HG--
extra : rebase_source : 40c39edce139f66fdb43b539b1d6fb0acb00d755
MainThreadInvoker queues both a Gecko runnable and an APC to the main thread to deal with different ways in which the main thread can block.
However, the main thread doesn't check for APCs very often any more.
This means that the APC's reference to the SyncRunnable doesn't get cleaned up for a long time, thus leaking memory.
To work around this, we:
1. Queue an APC wich does the actual work.
2. Post a Gecko runnable (which always runs).
If the APC hasn't run, the Gecko runnable runs it.
Otherwise, it does nothing.
MozReview-Commit-ID: L0P4rMBnlaZ
--HG--
extra : rebase_source : 3af871cf59e94818963e15881217218ef2b42b6c
Because Interceptors disable COM garbage collection to improve performance, they never receive Release calls from remote clients.
If the object can be shut down while clients still hold a reference, this function can be used to force COM to disconnect all remote connections (using CoDisconnectObject) and thus release the associated references to the Interceptor, its target and any objects associated with the HandlerProvider.
A HandlerProvider::DisconnectHandlerRemotes method also had to be added to allow HandlerProviders to disconnect clients for their own objects.
MozReview-Commit-ID: JaxEkOtrP1M
--HG--
extra : rebase_source : 2262af8fc3cb1aec8d9c8fc2762f3d61e188cb37
You'd think that MesHandleFree would free the buffer, since it was created by RPC, but it doesn't.
Therefore, we must free it ourselves using midl_user_free.
MozReview-Commit-ID: 9KzWTngFEEq
--HG--
extra : rebase_source : 6bee3903f619ec1cb1569ebf1df2ddef9da6b901
When an object is aggregated, doing a QI to anything other than IUnknown on the inner object AddRefs the outer object.
Thus, before releasing our reference to the inner IUnknown (and thus destroying it), we *must* release any references to interfaces queried from it.
Otherwise, any pointers to interfaces of the inner object would be invalidated.
MozReview-Commit-ID: KXsA8Sagx6G
--HG--
extra : rebase_source : f1dca4ee71f2ed49c8ba19c12862f2b4f9881fca
These conditions are rare and do indicate a problem which breaks accessibility.
However, we aren't getting any closer to diagnosing these as a result of these crashes, so they cause user pain without any gain to us.
MozReview-Commit-ID: D9U4et3Bg7d
--HG--
extra : rebase_source : a81263a0ef97a8ed87129d15ef30ded3005e740c
These conditions are rare and do indicate a problem which breaks accessibility.
However, we aren't getting any closer to diagnosing these as a result of these crashes, so they cause user pain without any gain to us.
MozReview-Commit-ID: D9U4et3Bg7d
--HG--
extra : rebase_source : a81263a0ef97a8ed87129d15ef30ded3005e740c
This fix is completely speculative, but I have strong reason to believe that
we are having lifetime issues, and that refcount stabilization might be coming
into play.
The situation is this:
Suppose we're aggregating an object, so we pass |this| as the outer IUnknown.
The inner object might perform AddRef() and Release() on |this| during its
initialization.
But if we're in the process of creating the outer object, that refcount might
not yet have been incremented by 1, so the inner object's invocation of the
outer object's Release() could trigger a deletion.
The way around this is to temporarily bump the refcount when aggregating another
object. The key, though, is to not do this via AddRef() and Release(), but by
direct maniuplation of the refcount variable, so that we don't trigger any of
the self-deletion stuff.
MozReview-Commit-ID: 3WA2AJvb6jY
--HG--
extra : rebase_source : ab05a52760541a4ab11f1245a5ddeae938998047
If QueryHandlerInterface returns E_NOINTERFACE, the proxy will be queried for the interface.
However, the handler might know that the interface is definitely not available and could thus avoid a pointless cross-process call.
To facilitate this, the handler can now return S_FALSE to signal that the proxy should not be queried, thus immediately returning E_NOINTERFACE to the client.
MozReview-Commit-ID: 4RtBsA9BTOV
--HG--
extra : rebase_source : 4b0dcb16c469361c1944b24568ceb83fd0ac09c1
This also enables the crash reporter on the MinGW build, as this is the
only thing blocking that from working.
MozReview-Commit-ID: Hygd7UUQvwl
--HG--
extra : rebase_source : a4a12b8edaa5b1fba869d6f7c21fc8444be2d9d7
StripHandlerFromOBJREF shortens the OBJREF by sizeof(CLSID), so it needs to seek the stream back after tweaking the OBJREF.
Previously, this was done using a relative seek.
Unfortunately, for some reason I can't fathom on Windows 7, this doesn't work when marshaling for VT_DISPATCH.
The Seek call succeeds, but either does nothing or sets the stream position to a garbage value.
Instead, we now use an absolute seek, which seems to behave.
This was breaking IAccessible::accNavigate and AccessibleChildren on Windows 7.
MozReview-Commit-ID: FEH93oiyP5R
--HG--
extra : rebase_source : b15db60da888b49cbd371bc5c8311577a2c7ece4
This patch adds two additional fields to each mscom log entry: The first is
the duration, in microseconds, of time spent in mscom overhead when executing
a call from the MTA on behalf of a remote client.
The second field is the duration, in microseconds, of time spent actually
executing the method within Gecko itself.
(In other words, the sum of the two fields will equal the total duration of
time spent executing the call.)
MozReview-Commit-ID: EhFieEPrhE5
Currently the Gecko Profiler defines a moderate amount of stuff when
MOZ_GECKO_PROFILER is undefined. It also #includes various headers, including
JS ones. This is making it difficult to separate Gecko's media stack for
inclusion in Servo.
This patch greatly simplifies how things are exposed. The starting point is:
- GeckoProfiler.h can be #included unconditionally;
- everything else from the profiler must be guarded by MOZ_GECKO_PROFILER.
In practice this introduces way too many #ifdefs, so the patch loosens it by
adding no-op macros for a number of the most common operations.
The net result is that #ifdefs and macros are used a bit more, but almost
nothing is exposed in non-MOZ_GECKO_PROFILER builds (including
ProfilerMarkerPayload.h and GeckoProfiler.h), and understanding what is exposed
is much simpler than before.
Note also that in BHR, ThreadStackHelper is now entirely absent in
non-MOZ_GECKO_PROFILER builds.
Ted Campbell
Sylvestre Ledru
Gabriele Svelto
Aaron Klotz
Narcis Beleuzu
Brindusan Cristian
Noemi Erli
Denis Palmeiro
Kirk Steuber
Jean-Yves Avenard
Cosmin Sabou
Ciure Andrei
Gerald Squelart
Dorel Luca
Nathan Froyd
Masatoshi Kimura
Coroiu Cristina
Brian Hackett
James Teh
Doug Thayer
Emilio Cobos Álvarez
Miko Mynttinen
Bogdan Tara
Andreea Pavel
Sebastian Hengst
Chris Peterson
shindli
Tom Ritter
Nicholas Nethercote