jemalloc_stats takes an array for its second argument. It expects this
array to have enough space for all the bins, previously the maximum was set
as a magic number. To make it dependent on the configured bins this patch
replaces the compile-time constant with a function.
Differential Revision: https://phabricator.services.mozilla.com/D127761
This also tightens the check for PHC-type crashes in the exception handler
so that we don't accidentally try to interpret unrelated crash types as
potential PHC ones.
Differential Revision: https://phabricator.services.mozilla.com/D126365
The codeql initialization process causes a loop in allocator
initialization that results in the inability to issue open()
calls due to function interception having begun set-up but
not completing it. (More details in bug.)
Differential Revision: https://phabricator.services.mozilla.com/D120521
"print" had no params so it wasn't doing anything, causing there
to be less newlines than needed.
The default stack frame width is a bit narrow, so I increased it.
There are a few new uninteresting functions showing up, so I've
added them to the allocator list.
Differential Revision: https://phabricator.services.mozilla.com/D118381
isspace requires data in libc to be initialised. If we're parsing
/proc/smaps before libc has initialised we need to provide our own
implementation.
Differential Revision: https://phabricator.services.mozilla.com/D116338
It was already disabled for fuzzed code-coverage in bug 1695331. My
guess is that fuzzed code-coverage tripped on the extra allocations
due to the code-coverage runtime, but the code-coverage builds didn't
trip it because they also triggered an exception, which further
triggered a bug in the code with python3 (and somehow the fuzzed ccov
builds didn't trigger that). That bug effectively masked the failure.
Differential Revision: https://phabricator.services.mozilla.com/D117383
BP may contain the stack address where the caller's BP was pushed after the function call, in which case it's possible to carefully unwind from it.
This can get past JIT code, so there is no need to give up in this case.
mozglue was already linked with ntdll, but now that we use it directly (for `NtQueryInformationThread`), ntdll needed to be added to some other users of MozStackWalkThread.
Differential Revision: https://phabricator.services.mozilla.com/D115962
Replay, moajemalloc_info, phc, and memory needed additional
pieces (mostly Printf.cpp and dependencies) to build
successfully on Windows.
Depends on D114651
Differential Revision: https://phabricator.services.mozilla.com/D114652
A long standing issue is that MOZ_ASSERT and related don't print stack
traces in debug builds when they're directly or indirectly emitted from
non-libxul code. Moving WalkTheStack to mozglue alleviates the problem.
It's also not printing stack traces when emitted from C code (and for
some C third party libraries, we do redirect assert to MOZ_ASSERT),
which we solve by making the corresponding API available without C++
(which WalkTheStack being a static method of the nsTraceRefCnt class
didn't allow, or the use of a closure on Android).
This requires some adjustements to headers that indirectly assume that
Assertions.h includes ErrorList.h through nsError.h through nscore.h
through nsTraceRefcnt.h.
We also remove TestStackCrawl.cpp because it hasn't been built since
bug 158528, 19 years ago.
Differential Revision: https://phabricator.services.mozilla.com/D108913
In the case of FramePointerStackwalk, the caller gives a pointer to the
top-most frame to walk from. There isn't really a reason to give a
number of frames to skip, as the right frame pointer could be given in
the first place if that was really necessary. And in practice, it's
hasn't been used so far.
In the case of MozStackWalkThread, the caller presumably doesn't know
what the thread the stack is being walked for is doing, and it would be
a guesswork to pass a valid number of frames to skip. In practice, it's
also not used.
The aSkipFrames is already a footgun on MozStackWalk (and we're going to
change that in bug 1515229), we don't need to keep a footgun on these
other stack walking methods.
Differential Revision: https://phabricator.services.mozilla.com/D108563
Instead of snprintf.
Because some standalone code uses those functions directly or indirectly,
and PrintfTarget lives in mozglue, they now need to depend on mozglue
instead of mfbt. Except logalloc/replay, which cherry-picks what it
uses, and the updater, for which we keep using vsnprintf.
Differential Revision: https://phabricator.services.mozilla.com/D103730
Paul Bone
criss
Marian-Vasile Laza
Alex Henrie
Mike Hommey
Gabriele Svelto
Tom Ritter
Andrew McCreight
Andrew Halberstadt
Alexandru Michis
Gerald Squelart
Andrey Bienkowski
Dorel Luca
Mitchell Hentges
Sandor Molnar
Ben Hearsum
Butkovits Atila
Bogdan Tara
Brindusan Cristian
Emilio Cobos Álvarez
Mike Hommey
Marco Castelluccio