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.
gcc throws a warning-as-error saying that the const qualifier will be ignored by function callers.
Remove the const qualifier to remove the warning.
MozReview-Commit-ID: JRQMz6Zdcdz
--HG--
extra : rebase_source : 687a7b310270823180b848d6c65cba7ba688b2ae
nsPrintfCString.h was not included, so it caused an error
GetStringValue was called before it was defined
MozReview-Commit-ID: HYoyWyaxqaZ
--HG--
extra : rebase_source : bf2c253cdba0c2fcf079a5b9bb275d39c6074f44
When removing our Windows message loop pumping code in the content
process, a11y code on the MTA thread must have some way to wake up the
main thread. The main thread could be blocked either on a conditional
variable waiting for a Gecko event, or it could be blocked waiting on
a Windows HANDLE in IPC code (doing a sync message send). In the
former case, we wake it up by posting an event to the main thread. In
the latter case, we continue to use the asynchronous procedure call
mechanism.
MozReview-Commit-ID: FN6KWaGo9Zl
Coroiu Cristina
Masatoshi Kimura
Gabriele Svelto
Cosmin Sabou
Brian Hackett
James Teh
Nathan Froyd
Doug Thayer
Emilio Cobos Álvarez
Dorel Luca
Aaron Klotz
Miko Mynttinen
Bogdan Tara
Andreea Pavel
Sebastian Hengst
Chris Peterson
shindli
NARCIS BELEUZU
Tom Ritter
Sylvestre Ledru
Nicholas Nethercote
Chris Manchester
Bevis Tseng
Wes Kocher
Ryan VanderMeulen
Georg Koppen
Bill McCloskey