This picks the same changes as the ones we just did to
memory/build/zone.c, plus a oneliner for sparc64.
--HG--
extra : rebase_source : ca917461472e8188fbfc6e2a971b228b68014e38
Some system libraries are using malloc_default_zone() and then using
some of the malloc_zone_* API. Under normal conditions, those functions
check the malloc_zone_t/malloc_introspection_t struct for the values
that are allowed to be NULL, so that a NULL deref doesn't happen.
As of OSX 10.12, malloc_default_zone() doesn't return the actual default
zone anymore, but returns a fake, wrapper zone. The wrapper zone defines
all the possible functions in the malloc_zone_t/malloc_introspection_t
struct (almost), and calls the function from the registered default zone
(jemalloc in our case) on its own. Without checking whether the pointers
are NULL.
This means that a system library that calls e.g.
malloc_zone_batch_malloc(malloc_default_zone(), ...) ends up trying to
call jemalloc_zone.batch_malloc, which is NULL, and crash follows.
So as of OSX 10.12, the default zone is required to have all the
functions available (really, the same as the wrapper zone), even if they
do nothing.
This is arguably a bug in libsystem_malloc in OSX 10.12, but jemalloc
still needs to work in that case.
[Adapted from
c6943acb3c]
--HG--
extra : rebase_source : 7d7a5b47fa18f56183e99c3655aee003c9be161e
The SDK jemalloc is built against might be not be the latest for various
reasons, but the resulting binary ought to work on newer versions of
OSX.
In order to ensure this, we need the fullest definitions possible, so
copy what we need from the latest version of malloc/malloc.h available
on opensource.apple.com.
[Adapted from
c68bb41793]
--HG--
extra : rebase_source : ab19c478b568ea24095a3be62c39fb81efc1920a
Change "include" match rule from "^include" to "include " since there might
be "skip-if" or other <failure-type> conditions before the "include". The
single space after is added so that tests like "include.html" won't be
excluded.
DONTBUILD because this patch modifies a script checking for the validity of
reftests, which is NPOTB.
MozReview-Commit-ID: 3tFFIo8RKFp
--HG--
extra : rebase_source : 970de4530aa2cb2aa65a0e017b6cd09de8aa2fdf
Because we read 8 bits from extradata, it won't exceed MAX_SPS/PPS_COUNT (256).
MozReview-Commit-ID: 5qr1pDLrmvt
--HG--
extra : rebase_source : 4a7269a7430ea913650298ad06a2132297dad85d
We have been using a different zone allocator between mozjemalloc and
replace-malloc for a long time. Jemalloc 4 uses the same as
replace-malloc, albeit as part of the jemalloc upstream code base.
We've been bitten many times in the past with Apple changes breaking the
zone allocator, and each time we've had to make changes to the three
instances, although two of them are similar and the changes there are
straightforward.
It also turns out that the way the mozjemalloc zone allocator is set up,
when a new version of OSX appears with a new version of the system zone
allocator, Firefox ends up using the system allocator, because the zone
allocator version is not supported.
So, we use the same zone allocator for both replace-malloc and
mozjemalloc, making everything on par with jemalloc 4.
--HG--
extra : rebase_source : 9c0e245b5f82bb71294370d607e690c05cc89fbc
The intent here is to reuse the zone allocator for mozjemalloc, to avoid
all the shortcomings of mozjemalloc using a different one. This change
only moves the replace-malloc zone allocator out of replace-malloc.c, to
make changes for mozjemalloc integration clearer.
--HG--
rename : memory/build/replace_malloc.c => memory/build/zone.c
extra : rebase_source : 8b98efaa4a88862f2967c855b511e92beb9c4031
Somehow, we never called those hooks when replace-malloc is enabled. I'd
expect this to cause random deadlocks when forking, and I'm surprised
this hasn't surfaced. Maybe it actually causes some intermittent oranges
on automation, who knows.
This also brings consistency with what is done for jemalloc 4, and with
the mozjemalloc implementation, too, that we're going to replace with
this one in a subsequent changeset.
--HG--
extra : rebase_source : 059567d17f928098db8367e9081b631ced351110
Unfortunately tinting the bookmark star is highly complicated due to the tinting
that NavigationView performs (i.e. we'd likely have to disable NavigationView
tinting, and do manual tinting on every icon - alternatively we could hack
the tint-list to use blue for "checked" items, and set the bookmark item
as checked). Since it's unclear if we even want the star to be blue,
we'll leave it grey (but filled) for now.
MozReview-Commit-ID: DekRZJayKIz
--HG--
extra : rebase_source : 1e3443e5f09c60bd0d7295bc35ecc08ca17b3dab
