MozStackWalk() is different on Windows to the other platforms. It has two extra
arguments, which can be used to walk the stack of a different thread.
This patch makes those differences clearer. Instead of having a single function
and forbidding those two arguments on non-Windows, it removes those arguments
from MozStackWalk, and splits off MozStackWalkThread() which retains them. This
also allows those arguments to have more appropriate types (HANDLE instead of
uintptr_t; CONTEXT* instead of than void*) and names (aContext instead of
aPlatformData).
The patch also removes unnecessary reinterpret_casts for the aClosure argument
at a couple of MozStackWalk() callsites.
--HG--
extra : rebase_source : 111ab7d6426d7be921facc2264f6db86c501d127
It's silly to use prmem.h within Firefox code given that in our configuration
its functions are just wrappers for malloc() et al. (Indeed, in some places we
mix PR_Malloc() with free(), or malloc() with PR_Free().)
This patch removes all uses, except for the places where we need to use
PR_Free() to free something allocated by another NSPR function; in those cases
I've added a comment explaining which function did the allocation.
--HG--
extra : rebase_source : 0f781bca68b5bf3c4c191e09e277dfc8becffa09
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
CLOSED TREE
Backed out changeset 01cfc71ce542 (bug 1322735)
Backed out changeset 84c729c41230 (bug 1322735)
Backed out changeset b419aaefae95 (bug 1322735)
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 : 5fe27cdeeb464d81fbedc8c02ac187658bd759e7
NS_LogCOMPtrAddRef and NS_LogCOMPtrRelease always pass false to
GetSerialNumber, because they pass in everything they get without
regard to whether it is being logged or not, so they don't want to
create a serial number if none exists. This causes the assertions
added in bug 1309051 to be hit. To work around this, I hoist the
assertion into the other callers of this method. Two of them already
had this check, but it was non-fatal.
This also makes the asserts not happen in release builds, as I decided
it doesn't really matter what happens if somebody tries to use it
there.
--HG--
extra : rebase_source : 5e70290492fd442b79b4d40c300a263e322f485b
This is an unrelated change to fix an issue that was bothering me.
MozReview-Commit-ID: Cxw9WhHfSAf
--HG--
extra : rebase_source : 10e3b3f28ecad0af216dbb368ffdb3b0ff75c7f9
Nobody asks for the new stats, only the total ones, so there's no need
for two sets of statistics.
MozReview-Commit-ID: AO0ue9MPn3N
--HG--
extra : rebase_source : 8d5237c4efdc0ece5bf1a386cae38e394aaadf01
Only about:bloat used NEW_STATS, so act like we have ALL_STATS
everywhere. A later patch will remove the mNewStats field.
MozReview-Commit-ID: LUJBpS3iYht
--HG--
extra : rebase_source : 543951314e12e7964e3f25c155b658d50ce674a6
DumpStatistics does not track any objects that are created or
destroyed while it is running, which means that any subsequent calls
to it will produce incorrect results. This can lead to incorrect
positive or negative leaks being reported. See 1271182.
Now that about:bloat has been removed, DumpStatistics should only be
called once, during shutdown.
MozReview-Commit-ID: IjMkExeBRBr
--HG--
extra : rebase_source : 5966789c2febfedc796d17f8589e8c3703d266cb
This doesn't add comments for all of them, just some of those spread
out over many lines. The lack of these comments made writing part 1
more annoying.
GetSerialNumber accesses global state through gSerialNumbers. We call
GetSerialNumber under a lock when doing normal object refcount logging.
However, we call GetSerialNumber outside of a lock when we're tracing
individual classes for nsCOMPtr refcount logging, even if we don't
actually care about nsCOMPtr refcount logging. We should call it under
a lock always.
This will ensure we properly parse class names containing spaces.
Note that if a class name somehow ends up containing operator| then this will end up again silently failing.
