OBSERVE_LATE_WRITES is now always defined, we can just remove it.
MozReview-Commit-ID: El6RnzZnXBN
--HG--
extra : rebase_source : 95fe63562b88c61ee5915e28a3a8b89c985042db
With frame pointer omission disabled we should always have usable stacks on Windows. This allows us to remove the MOZ_STACKWALKING define as it will always be enabled.
MozReview-Commit-ID: 54xs3Hf1r4P
--HG--
extra : rebase_source : dfaf13fb4c2185985f4f074c338ccf1fef8f3c94
In the 32-bit parisc runtime, the first four non floating-point
arguments are passed in registers (%r26, %r25, %r24 and %r23).
The remaining arguments are passed on the stack. There are four
reserved slots on the stack that the callee can use to save the
first four argument registers if the callee desires.
The StubN functions are special in that arguments are not explicitly
declared. %r26 is used for the "self" pointer. The call to SharedStub(n)
loads n into %r26 and clobbers the "self" pointer in %r26. The hppa
SharedStub implementation expects to find the "self" pointer on the
stack in the slot reserved for StubN. However, gcc doesn't copy any
arguments to the stack as no arguments are declared for StubN. Even
if it did, there's no guarantee that we could force gcc to save the
argument on the stack as that's more expensive than copying to a
free register. Thus, we need to copy %r26 to the stack slot manually.
Bug 1295053 removed most uses of NS_METHOD and NS_CALLBACK, but one use was
unintentionally left behind (in the XPIDL parser) and another has since crept
in (in MediaDrmCDMProxy.h).
So this patch removes NS_METHOD and NS_CALLBACK. NS_METHOD_(nsresult) and
NS_CALLBACK_(nsresult, T) can still be used for the same purpose, but those
alternatives are less likely to be used unintentionally.
--HG--
extra : rebase_source : a50fc7b2a64a36d1ca9beda81bc0edb8f2ec1934
In some parts of the crash reporter, we need to disable I/O
interposition, then turn it back on. We didn't have a function for
re-enabling the I/O interposer...until now.
This test alone would fail to even build without the previous patch,
demonstrating the issue at hand, where the method-pointer from the base class
forces NewRunnableMethod to store a pointer to that base class in a RefPtr,
which is not possible when that base class is not ref-counted.
MozReview-Commit-ID: 9XaQ8SwMqVo
--HG--
extra : rebase_source : 3ba0e13fb76ef2c5969084334c2f11e3f445d11f
This is done by storing the object pointer based on the exact pointee type,
instead of as hinted by the method-pointer, which could be a non-refcounted
base class.
The stored pointer type is statically-checked to be derived from (or the same
as) the class type from the method-pointer, to prevent misuses.
One change had to be done in TrackBuffersManager, as it was passing another
type and relying on implicit pointer conversions. A simple `.get()` to pass
the raw pointer type (to be stored in a RefPtr) fixed that one issue.
MozReview-Commit-ID: 4kH0XdjB5Rk
--HG--
extra : rebase_source : 40ad68820cfce469ecda272f430062f05dfcd09f
This test alone would fail to even build without the previous patch,
demonstrating the issue at hand, where the method-pointer from the base class
forces NewRunnableMethod to store a pointer to that base class in a RefPtr,
which is not possible when that base class is not ref-counted.
MozReview-Commit-ID: 9XaQ8SwMqVo
--HG--
extra : rebase_source : 5c752e1a16af8e8f976853396228abff2c76c43c
This is done by storing the object pointer based on the exact pointee type,
instead of as hinted by the method-pointer, which could be a non-refcounted
base class.
The stored pointer type is statically-checked to be derived from (or the same
as) the class type from the method-pointer, to prevent misuses.
One change had to be done in TrackBuffersManager, as it was passing another
type and relying on implicit pointer conversions. A simple `.get()` to pass
the raw pointer type (to be stored in a RefPtr) fixed that one issue.
MozReview-Commit-ID: 4kH0XdjB5Rk
--HG--
extra : rebase_source : 3eb7fa3cb1873f71b4d5e7118d2dc48f6fdf2874
Implemented in the same style as RemovePointer and RemoveSmartPointer, for
consistency.
It could have been done by invoking the latter two, but I didn't want to add an
unnecessary extra layer of templates; the cost of the code duplication should
be negligible.
MozReview-Commit-ID: IH4lZkbRYGZ
--HG--
extra : rebase_source : b9b9a07a03fab768fc88b300c33627b3179a81da
Just a straight move, no code changes.
This will be needed in bug 1329319, as some new code higher in the file will
rely on RemoveSmartPointer. Since the next patch will pretty much rewrite
RemoveSmartPointer anyway, I thought I might as well make the big move
right now, to keep better history/blame of the upcoming changes.
MozReview-Commit-ID: A2lMUFHFWg4
--HG--
extra : rebase_source : 8470a0f7e2e6892e9d9c2e4eef1c44d8f73d2dad
Then and ThenPromise can now be given only one member function, which takes a
`const MozPromise::ResolveOrRejectValue&`.
MozReview-Commit-ID: 5Zm0i27GHcA
--HG--
extra : rebase_source : 1ed068681616fa0aa5fa77f8dbf78ccbd727f363
Then and ThenPromise can now be given only one function object, which takes a
`const MozPromise::ResolveOrRejectValue&`.
MozReview-Commit-ID: BEtc3spK9Yh
--HG--
extra : rebase_source : 1b16ad15ebfcdfb653d8d98073adee0f8b27b46e
Removed 'virtual' from overrides, as per coding guidelines.
Fixed some incorrect indentations, and inconsistencies.
MozReview-Commit-ID: 4kNVgoDljG3
--HG--
extra : rebase_source : 7b25abacc7cfc1a6898963bc58120204c70bee45
As far as I can tell, this covers all the remaining threads which we start
using PR_CreateThread, except the ones that are created inside NSPR or NSS,
and except for the Shutdown Watchdog thread in nsTerminator.cpp and the
CacheIO thread. The Shutdown Watchdog thread stays alive past leak detection
during shutdown (by design), so we'd report leaks if we profiled it. The
CacheIO thread seems to stay alive past shutdown leak detection sometimes as
well.
This adds a AutoProfilerRegister stack class for easy registering and
unregistering. There are a few places where we still call
profiler_register_thread() and profiler_unregister_thread() manually, either
because registration happens conditionally, or because there is a variable that
gets put on the stack before the AutoProfilerRegister (e.g. a dynamically
generated thread name). AutoProfilerRegister needs to be the first object on
the stack because it uses its own `this` pointer as the stack top address.
MozReview-Commit-ID: 3vwhS55Yzt
--HG--
extra : rebase_source : 56dd27282e7bd09a7e7dc7ca09ccfe3a0198e7af
The point of this exercise is to make the thread name available in the thread
func of the thread, so that we can register the thread with the profiler from
the very start of its lifetime, and so that registration and unregistration
can be inside the same function.
MozReview-Commit-ID: DiiMKUQVr55
--HG--
extra : rebase_source : 24b15d56315ad49e72b3e9b76db7fb634f3bfe01
As far as I can tell, this covers all the remaining threads which we start
using PR_CreateThread, except the ones that are created inside NSPR or NSS.
This adds a AutoProfilerRegister stack class for easy registering and
unregistering. There are a few places where we still call
profiler_register_thread() and profiler_unregister_thread() manually, either
because registration happens conditionally, or because there is a variable that
gets put on the stack before the AutoProfilerRegister (e.g. a dynamically
generated thread name). AutoProfilerRegister needs to be the first object on
the stack because it uses its own `this` pointer as the stack top address.
MozReview-Commit-ID: 3vwhS55Yzt
--HG--
extra : rebase_source : 9deaace277db2f63c520325be27f6ed97aa65ac9
Hiroyuki Ikezoe
Ben Kelly
JW Wang
Carsten "Tomcat" Book
Eric Rahm
John David Anglin
John Paul Adrian Glaubitz
Nicholas Nethercote
Nathan Froyd
Gerald Squelart
Kate McKinley
Wes Kocher
Ryan VanderMeulen
Xidorn Quan
Markus Stange
Cervantes Yu
Chris Peterson
Olli Pettay