Defines an android-only version of nsTraceRefcnt::WalkTheStack that takes a function callback, which outputs the stack frame buffer to `__android_log_print`. Also uses `__wrap_dladdr` in MozDescribeCodeAddress, which outputs slightly more informative data for the stack trace (instead of instances of '???/??? [???]').
Differential Revision: https://phabricator.services.mozilla.com/D46868
--HG--
extra : moz-landing-system : lando
Defines an android-only version of nsTraceRefcnt::WalkTheStack that takes a function callback, which outputs the stack frame buffer to `__android_log_print`. Also uses `__wrap_dladdr` in MozDescribeCodeAddress, which outputs slightly more informative data for the stack trace (instead of instances of '???/??? [???]').
Differential Revision: https://phabricator.services.mozilla.com/D46868
--HG--
extra : moz-landing-system : lando
None of the StringTable implementations were freeing their strdup'd
strings, either.
Differential Revision: https://phabricator.services.mozilla.com/D40757
--HG--
extra : moz-landing-system : lando
It relies on AC_TRY_RUN, which doesn't work on cross-compiles. What this
means is that the feature has been disabled on mac builds on automation
ever since we switched to cross-compiles. It's still enabled on local
mac builds because the test runs there, and returns "yes". It also means
it's disabled on Android, where it probably works (at least debug tests
on try don't complain).
It also doesn't currently run on Windows because it's in a skipped
section on Windows, but if moved out of that section, the test returns
"no".
So, we remove any configure test for the feature, in favor of
preprocessor checks in nsTraceRefcnt.cpp.
Depends on D18055
Differential Revision: https://phabricator.services.mozilla.com/D18056
--HG--
extra : moz-landing-system : lando
In order to test the test harness's handling of a process failing to
produce a leak log, add a special function that disables the bloat log
output.
Differential Revision: https://phabricator.services.mozilla.com/D17534
--HG--
extra : moz-landing-system : lando
nsCRTGlue.cpp has a few data tables that get broken up badly by
clang-format, so just disable the formatting. There are some more
tables in this file, but the arrangement doesn't seem to matter for
them.
The bloat log header is just a little bit of ASCII art, so just ignore
it in formatting so it is easier to read.
MOZ_COLLECT_REPORT uses very wide string constants that get rewrapped
in an ugly way by clang-format, so just disable the formatting for
them.
Depends on D13185
Differential Revision: https://phabricator.services.mozilla.com/D13186
--HG--
extra : moz-landing-system : lando
clang-format doesn't seem to reflow text when a single string constant
is represented as multiple lines of string literals to fit within 80
columns. Instead, if a single string literal is too long, it breaks
off a piece and moves it to the next line, which leads to a bunch of
choppy short string bits. The resulting string literals are still a
bit choppy, mostly because I didn't want to break up the long names of
prefs.
Here's an example of what I mean:
|--- max width --- |
"some long string literal"
"is here but it goes on for multiple lines"
This gets turned into:
|--- max width --- |
"some long string "
"literal"
"is here but it "
"goes on for multiple lines"
My patch manually would turn this into:
|--- max width --- |
"some long string "
"literal is here "
"but it goes on "
"for multiple lines"
The strings in my patch don't always end up at column 80, because the
width is set to work with wherever clang format ends up actually
indenting them.
There are more instances of this problem when MOZ_COLLECT_REPORT is
used, but that can be dealt with in another bug. There are a ton of
them.
Depends on D13184
Differential Revision: https://phabricator.services.mozilla.com/D13185
--HG--
extra : moz-landing-system : lando
Clang format does not always reflow comments correctly to get them
within 80 columns.
The major categories of failures I have noticed in xpcom/ are:
- Comments that are lists. I fixed these by manually getting them so
they'll be within 80 columns after clang-format runs.
- Comments intermixed with lists of things like enums, initializers,
or even fields in a class. It doesn't seem to associate the comment
with the item in the list correctly. The worst cases of these happen
when it changes initializer lists from having commas at the start of
each item to having them at the end. In the initializer comma cases,
I fixed them by making the commas at the end, so clang-format won't
mix things up. For other cases, I often moved the comment for an
item onto its own line, because it was not possible to have both the
comment and the item on the same line and stay within 80 columns.
- One odd case is nsEnumeratorUtils.cpp, where the end of line comment
after a NS_DECL macro confused clang-format and made it stop
realizing that the NS_DECL thing was a complete statement. I also
added a blank line to that file before a declaration because I think
that is better.
Depends on D13183
Differential Revision: https://phabricator.services.mozilla.com/D13184
--HG--
extra : moz-landing-system : lando
Inheriting PerThreadAtomCache on CycleCollectedJSContext permits use of
static_cast, avoiding one level of indirection compared to adding a
CycleCollectedJSContext* to PerThreadAtomCache.
PerThreadAtomCache is over 18kB, and so WorkerJSContext and WorkletJSContext
are moved from the stack to the heap.
MozReview-Commit-ID: 6jdJeZcviK4
--HG--
extra : rebase_source : 3c2accb71faf3f017a44c405ae0484e57aaf039c
...on Windows, at least. Apparently if you have environment variables
set that contain multibyte characters, and ask for them with getenv, you
get garbage. Or perhaps you get something sensible, but then passing it
to fopen produces garbage. Either way, the most reasonable way to
handle this is to use the Windows wide-character APIs all over.
This patch adds a new environment variable XPCOM_MEM_LOG_JS_STACK that
changes XPCOM leakchecking to record a JS stack for all objects, in
addition to a C++ stack. This is useful when a C++ object is being
leaked due to JS. The JS stack will be printed if the object leaks, if
it is used in combination with XPCOM_MEM_BLOAT_LOG=1 and
XPCOM_MEM_LOG_CLASSES=nsFoo, if nsFoo is the class of interest.
This patch moves a few XPConnect functions for recording the stack
into xpcpublic.h so they can be called from nsTraceRefcnt.cpp.
MozReview-Commit-ID: FX2QVCSXz4f
--HG--
extra : rebase_source : 5bd4e341072f4cf7d3be774b63d2107479fe9985
Most subclasses of Runnable don't bother to override AddRef and
Release, so XPCOM leak checking ends up reporting Runnable, which
makes it impossible to know what is actually leaking.
Each subclass of Runnable is already required to pass in the name of
the class, which is stored in the field mName. This patch changes
Runnable to use mName as the class name for XPCOM leak checking, thus
giving each subclass a specific name without needing to change the
hundreds of existing subclasses of Runnable.
The limitation of this approach is the classes that DO use
NS_IMPL_ADDREF/RELEASE_INHERITED end up using the same class name that
is used by the superclass AddRef/Release, but with a different size,
which causes assertions in the leak checker. To work around this, I
change NS_IMPL_ADDREF/RELEASE_INHERITED to not call into
NS_LOG_ADDREF/RELEASE for classes that are a subclass of
Runnable. This needs to use IsConvertible<> and not IsBaseOf<> because
the latter requires the classes involved to be defined, and headers
can use nsISupportsImpl.h without nsThreadUtils.h.
MozReview-Commit-ID: H0pgvwQSZAE
--HG--
extra : rebase_source : 0be13fe2e649e62be1f9471fc03fac43024eb0aa
And remove unreachable code after MOZ_CRASH_UNSAFE_OOL().
MOZ_CRASH_UNSAFE_OOL causes data collection because crash strings are annotated to crash-stats and are publicly visible. Firefox data stewards must do data review on usages of this macro. However, all the crash strings this patch collects with MOZ_CRASH_UNSAFE_OOL are already collected with NS_RUNTIMEABORT.
MozReview-Commit-ID: IHmJfuxXSqw
--HG--
extra : rebase_source : 031f30934b58a7b87f960e57179641d44aefe5c5
extra : source : fe9f638a56a53c8721eecc4273dcc074c988546e
It seemingly hasn't been needed since Mac OS 10.7. A diagnostic assertion that
has been in place for a while hasn't caught any uses of it.
--HG--
extra : rebase_source : 9834849eec9174267c7df8de7fd22840ffa36d8f
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.