Closed Bug 788955 Opened 12 years ago Closed 12 years ago

make heap-allocated memory statistics work on FreeBSD

Categories

(Core :: Memory Allocator, defect)

x86_64
FreeBSD
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla19
Tracking Status
firefox19 --- fixed
b2g18 --- fixed

People

(Reporter: jbeich, Assigned: jbeich)

References

Details

Attachments

(6 files, 24 obsolete files)

853 bytes, patch
glandium
: review+
Details | Diff | Splinter Review
13.45 KB, patch
glandium
: review+
justin.lebar+bug
: approval-mozilla-b2g18+
Details | Diff | Splinter Review
1.32 KB, patch
Details | Diff | Splinter Review
1017 bytes, patch
Details | Diff | Splinter Review
4.08 KB, patch
Details | Diff | Splinter Review
8.48 KB, patch
Details | Diff | Splinter Review
      No description provided.
Attachment #658802 - Flags: review?(mh+mozilla)
about:memory before:

WARNING: the 'heap-allocated' memory reporter does not work for this platform and/or configuration. This means that 'heap-unclassified' is not shown and the 'explicit' tree shows less memory than it should.

about:memory after:

WARNING: the following values are negative or unreasonably large.
 heap-committed
 heap-committed-unused
 heap-dirty
This indicates a defect in one or more memory reporters.  The invalid values are highlighted.
...
      70.28 MB ── heap-allocated
      -0.00 MB ── heap-committed [?!]
     -70.28 MB ── heap-committed-unused [?!]
2503030128.82% ── heap-committed-unused-ratio
      -0.00 MB ── heap-dirty [?!]
Comment on attachment 658802 [details] [diff] [review]
Bug 788955 - Add support for system jemalloc3 on FreeBSD.

Review of attachment 658802 [details] [diff] [review]:
-----------------------------------------------------------------

::: configure.in
@@ +6908,5 @@
> +      if test "$ac_cv_func_mallctl" = "yes" -a \
> +              "$ac_cv_func_nallocm" = "yes"; then
> +        MOZ_NATIVE_JEMALLOC=1
> +        MOZ_MEMORY=1
> +        MOZ_JEMALLOC=1

I don't think this should be the default. BTW, I see freebsd doesn't build with jemalloc at all by default, is there a particular reason?

@@ +7000,5 @@
>      AC_MSG_ERROR([--enable-jemalloc not supported on ${target}])
>      ;;
>    esac
>  fi # MOZ_MEMORY
> +AC_SUBST(MOZ_NATIVE_JEMALLOC)

You also want to skip the jemalloc sub-configure at the end of this file.

::: memory/jemalloc/Makefile.in
@@ +18,5 @@
>  SDK_LIBRARY = $(REAL_LIBRARY)
>  DIST_INSTALL = 1
>  endif
>  
> +ifndef MOZ_NATIVE_JEMALLOC

Please move this test to top-level Makefile.in, so that you don't go under memory/jemalloc at all.

::: toolkit/library/Makefile.in
@@ +345,5 @@
>    $(MOZ_APP_EXTRA_LIBS) \
>    $(SQLITE_LIBS) \
>    $(NULL)
>  
> +ifdef MOZ_NATIVE_JEMALLOC

ifndef
Attachment #658802 - Flags: review?(mh+mozilla) → review-
This should have been in bug 778056.
Attachment #659187 - Flags: review?(justin.lebar+bug)
(In reply to Mike Hommey [:glandium] from comment #3)
> I don't think this should be the default.

jemalloc3 (in libc) is available only on 10.0-CURRENT which is development version and going to be at least until Spring 2013 (my rough guess).

> BTW, I see freebsd doesn't build with jemalloc at all by default, is there a particular reason?

memory/mozjemalloc crashes in malloc_init(), at least on 10.0-CURRENT. memory/jemalloc seems to work fine. This may differ on old system jemalloc, e.g. in 9.1-RELEASE.

As for default, I think the whole block with

  *-*linux*)
  ...
      MOZ_MEMORY=1
  ...

can be shared with FreeBSD but it needs merging _linux.cfg and _freebsd.cfg.
Attachment #658802 - Attachment is obsolete: true
Attachment #659188 - Flags: review?(mh+mozilla)
v3. If mallctl/nallocm are available and MOZ_MEMORY is not defined use MOZ_NATIVE_JEMALLOC on every system. Currently, hidden under MOZ_JEMALLOC environment variable except for FreeBSD.
Attachment #659202 - Flags: review?(mh+mozilla)
Attachment #659188 - Attachment is obsolete: true
Attachment #659188 - Flags: review?(mh+mozilla)
Attachment #659202 - Attachment description: Bug 788955 - Add support for system jemalloc on FreeBSD. → Bug 788955, part 2 - Add support for system jemalloc on FreeBSD.
Comment on attachment 659187 [details] [diff] [review]
Bug 788955 - Check for malloc_usable_size() via autoconf.

I remain blissfully ignorant of this autoconf goop.
Attachment #659187 - Flags: review?(justin.lebar+bug) → review?(mh+mozilla)
Martin, what's the prospect of updating old version of jemalloc in NetBSD to the one on canonware.com? Any chance it'll expose non-standard API like FreeBSD (e.g. malloc_usable_size, mallctl, nallocm) for use in Firefox?
Comment on attachment 659187 [details] [diff] [review]
Bug 788955 - Check for malloc_usable_size() via autoconf.

Review of attachment 659187 [details] [diff] [review]:
-----------------------------------------------------------------

This looks good, but i'd rather see TryServer results.
Attachment #659187 - Flags: review?(mh+mozilla) → review+
Comment on attachment 659202 [details] [diff] [review]
Bug 788955, part 2 - Add support for system jemalloc on FreeBSD.

Review of attachment 659202 [details] [diff] [review]:
-----------------------------------------------------------------

::: configure.in
@@ +6914,5 @@
> +       AC_DEFINE(MOZ_NATIVE_JEMALLOC)
> +       AC_DEFINE(MOZ_MEMORY)
> +       AC_DEFINE(MOZ_JEMALLOC)],
> +      [MOZ_NATIVE_JEMALLOC= MOZ_MEMORY=])
> +  fi

With MOZ_JEMALLOC=1 set even when mallctl/nallocm are not available (aiui, that's the case on current freebsd), I'm doubtful this works properly.

::: toolkit/library/Makefile.in
@@ +347,5 @@
>    $(NULL)
>  
> +ifdef MOZ_NATIVE_JEMALLOC
> +EXTRA_DSO_LDOPTS += $(call EXPAND_LIBNAME_PATH,memory,$(DIST)/lib)
> +endif

You shouldn't need this.
Attachment #659202 - Flags: review?(mh+mozilla) → review-
(In reply to Jan Beich from comment #8)
> Martin, what's the prospect of updating old version of jemalloc in NetBSD to
> the one on canonware.com? Any chance it'll expose non-standard API like
> FreeBSD (e.g. malloc_usable_size, mallctl, nallocm) for use in Firefox?

We are looking at the former (but it is non trivial, lots of diverging changes).
Not sure the latter will happen though - are there big benefits from the api extensions?
Blocks: 791366
(In reply to Jan Beich from comment #5)
> memory/jemalloc seems to work fine

Ah, it doesn't even survive gcc_hidden.h, only -fvisibility=hidden provided by upstream.

dist/lib/libmemory.a(mutex.o): In function `malloc_mutex_init':
/a/mozilla-central/memory/jemalloc/src/src/mutex.c:(.text.malloc_mutex_init+0x44): undefined reference to `_pthread_mutex_init_calloc_cb'
dist/lib/libmemory.a(mutex.o): In function `mutex_boot':
memory/jemalloc/src/src/mutex.c:(.text.mutex_boot+0x2f): undefined reference to `_pthread_mutex_init_calloc_cb'
/usr/bin/ld: js: hidden symbol `_pthread_mutex_init_calloc_cb' isn't defined
/usr/bin/ld: final link failed: Bad value
Attachment #662099 - Flags: review?(mh+mozilla)
(In reply to Mike Hommey [:glandium] from comment #10)
> > +ifdef MOZ_NATIVE_JEMALLOC
> > +EXTRA_DSO_LDOPTS += $(call EXPAND_LIBNAME_PATH,memory,$(DIST)/lib)
> > +endif
> 
> You shouldn't need this.

Like this? Except it doesn't survive -Wl,z,defs. Neither --enable-jemalloc.

xpcom/base/nsMemoryReporterManager.o: In function `MemoryReporter_HeapAllocated::GetAmount(long*)':
xpcom/base/nsMemoryReporterManager.cpp:(.text._ZN28MemoryReporter_HeapAllocated9GetAmountEPl[_ZN28MemoryReporter_HeapAllocated9GetAmountEPl]+0x11): undefined reference to `jemalloc_stats'
xpcom/base/nsMemoryReporterManager.o: In function `MemoryReporter_HeapUnused::GetAmount(long*)':
xpcom/base/nsMemoryReporterManager.cpp:(.text._ZN25MemoryReporter_HeapUnused9GetAmountEPl[_ZN25MemoryReporter_HeapUnused9GetAmountEPl]+0x11): undefined reference to `jemalloc_stats'
xpcom/base/nsMemoryReporterManager.o: In function `MemoryReporter_HeapCommitted::GetAmount(long*)':
xpcom/base/nsMemoryReporterManager.cpp:(.text._ZN28MemoryReporter_HeapCommitted9GetAmountEPl[_ZN28MemoryReporter_HeapCommitted9GetAmountEPl]+0x11): undefined reference to `jemalloc_stats'
xpcom/base/nsMemoryReporterManager.o: In function `MemoryReporter_HeapCommittedUnused::GetAmount(long*)':
xpcom/base/nsMemoryReporterManager.cpp:(.text._ZN34MemoryReporter_HeapCommittedUnused9GetAmountEPl[_ZN34MemoryReporter_HeapCommittedUnused9GetAmountEPl]+0x11): undefined reference to `jemalloc_stats'
xpcom/base/nsMemoryReporterManager.o: In function `MemoryReporter_HeapCommittedUnusedRatio::GetAmount(long*)':
xpcom/base/nsMemoryReporterManager.cpp:(.text._ZN39MemoryReporter_HeapCommittedUnusedRatio9GetAmountEPl[_ZN39MemoryReporter_HeapCommittedUnusedRatio9GetAmountEPl]+0x11): undefined reference to `jemalloc_stats'
xpcom/base/nsMemoryReporterManager.o:xpcom/base/nsMemoryReporterManager.cpp:(.text._ZN24MemoryReporter_HeapDirty9GetAmountEPl[_ZN24MemoryReporter_HeapDirty9GetAmountEPl]+0x11): more undefined references to `jemalloc_stats' follow
Attachment #659202 - Attachment is obsolete: true
Attachment #662103 - Flags: review?(mh+mozilla)
Just change the definition of jemalloc_stats in memory/mozjemalloc/jemalloc.h such that it is properly weak on freebsd.
Comment on attachment 662099 [details] [diff] [review]
Bug 788955 - Prevent pragma visibility from hiding _pthread_mutex_init_calloc_cb on FreeBSD.

Review of attachment 662099 [details] [diff] [review]:
-----------------------------------------------------------------

Please upstream this.
Attachment #662099 - Flags: review?(mh+mozilla) → review+
trivial change: added malloc_np.h to system-headers
Attachment #659187 - Attachment is obsolete: true
Attachment #662103 - Attachment is obsolete: true
Attachment #662103 - Flags: review?(mh+mozilla)
Attachment #662439 - Flags: review?(mh+mozilla)
This fixes linking libxul.so with --enable-jemalloc and not using -Wl,--warn-unresolved-symbols.
Attachment #662440 - Flags: review?(mh+mozilla)
This fixes bogus stats with --enable-jemalloc, e.g. heap-allocated being always 0.
Attachment #662442 - Flags: review?(mh+mozilla)
Comment on attachment 662439 [details] [diff] [review]
Bug 788955 - Without --enable-jemalloc use jemalloc3 in libc if available.

Review of attachment 662439 [details] [diff] [review]:
-----------------------------------------------------------------

::: Makefile.in
@@ +46,5 @@
>  endif
>  
>  ifdef MOZ_MEMORY
>  tier_base_dirs += memory/mozjemalloc
> +ifeq (1_,$(MOZ_JEMALLOC)_$(MOZ_NATIVE_JEMALLOC))

it would be clearer in the form
ifdef MOZ_JEMALLOC
ifndef MOZ_NATIVE_JEMALLOC

::: configure.in
@@ +6964,5 @@
> +  MOZ_NATIVE_JEMALLOC=1
> +  AC_CHECK_FUNCS(mallctl nallocm,,
> +    [MOZ_NATIVE_JEMALLOC=
> +     break])
> +  if test -n "$MOZ_NATIVE_JEMALLOC" -a -n "$MOZ_JEMALLOC"; then

Shouldn't the MOZ_JEMALLOC check be around the entire block you add?

::: memory/build/mozjemalloc_compat.c
@@ +10,5 @@
> +#endif
> +
> +#if defined(MOZ_NATIVE_JEMALLOC)
> +#define je_mallctl mallctl
> +#endif

#else

::: memory/mozjemalloc/jemalloc.h
@@ +32,5 @@
>  #ifndef _JEMALLOC_H_
>  #define _JEMALLOC_H_
>  
> +#if defined(MALLOC_H)
> +#include MALLOC_H /* for nallocm and malloc_good_size  */

/* for nallocm on system jemalloc and malloc_good_size on mac */

::: mozglue/build/Makefile.in
@@ +22,5 @@
>  FORCE_STATIC_LIB = 1
>  endif
>  
>  # Keep jemalloc separated when mozglue is statically linked
> +ifeq (1_1,$(MOZ_MEMORY)_$(or $(FORCE_SHARED_LIB),$(MOZ_NATIVE_JEMALLOC)))

Kind of awful, but I have nothing better to suggest :-/
Attachment #662439 - Flags: review?(mh+mozilla) → review+
Attachment #662440 - Flags: review?(mh+mozilla) → review+
Attachment #662442 - Flags: review?(mh+mozilla) → review+
With malloc_conf actually passed to system jemalloc I find memory consumption more sane when using GL layers.

(In reply to Mike Hommey [:glandium] from comment #20)
> ::: memory/build/mozjemalloc_compat.c
> @@ +10,5 @@
> > +#endif
> > +
> > +#if defined(MOZ_NATIVE_JEMALLOC)
> > +#define je_mallctl mallctl
> > +#endif
> 
> #else

It's also used by --enable-jemalloc on FreeBSD to rename extern declaration further below in the file.
Attachment #662439 - Attachment is obsolete: true
Attachment #663279 - Flags: review?(mh+mozilla)
trivial change: resolve conflict
Attachment #662440 - Attachment is obsolete: true
trivial change: add decls in extraMallocFuncs.c
Attachment #662442 - Attachment is obsolete: true
(In reply to Mike Hommey [:glandium] from comment #20)
> ::: memory/mozjemalloc/jemalloc.h
> @@ +32,5 @@
> >  #ifndef _JEMALLOC_H_
> >  #define _JEMALLOC_H_
> >  
> > +#if defined(MALLOC_H)
> > +#include MALLOC_H /* for nallocm and malloc_good_size  */
> 
> /* for nallocm on system jemalloc and malloc_good_size on mac */

How about just using more explicit ifdef?
Attachment #663283 - Flags: review?(mh+mozilla)
(In reply to Jan Beich from comment #5)
> memory/mozjemalloc crashes in malloc_init(), at least on 10.0-CURRENT.

On FreeBSD it should use _pthread_mutex_init_calloc_cb. Looking at the implementation in jemalloc3 and ifdef'd out pieces in mozjemalloc this shouldn't be hard to do. But after poking for a hour it still crashed in choose_arena() so I gave up.
trivial change: add include to extraMallocFuncs.c

This should protect against redefinition of 'foo' with a different type.
Attachment #663283 - Attachment is obsolete: true
Attachment #663283 - Flags: review?(mh+mozilla)
Attachment #663429 - Flags: review?(mh+mozilla)
trivial change: don't even generate memory/jemalloc/Makefile, it's unused and broken with MOZ_NATIVE_JEMALLOC
Attachment #663279 - Attachment is obsolete: true
Attachment #663279 - Flags: review?(mh+mozilla)
Attachment #663431 - Flags: review?(mh+mozilla)
trivial change: apply to js/src/configure.in, too
Attachment #662438 - Attachment is obsolete: true
Attachment #663429 - Flags: review?(mh+mozilla)
Comment on attachment 663431 [details] [diff] [review]
Bug 788955 - Without --enable-jemalloc detect and use jemalloc3 in libc. r=glandium

Can you post a single patch with everything, because this is getting more and more confusing.
Attachment #663431 - Flags: review?(mh+mozilla)
Attached patch cumulative (obsolete) — Splinter Review
My intent is
- make --enable-jemalloc (jemalloc 3.0.0) work on FreeBSD
- try using jemalloc 3.0.0 API if available without --enable-jemalloc

(In reply to Mike Hommey [:glandium] from comment #29)
> Can you post a single patch with everything, because this is getting more
> and more confusing.

OK, but I want it committed in granular bits.
Attachment #663968 - Flags: review?(mh+mozilla)
hidden malloc_message cannot override jemalloc function in libc
Attachment #663431 - Attachment is obsolete: true
Attached patch cumulative (obsolete) — Splinter Review
Attachment #663968 - Attachment is obsolete: true
Attachment #663968 - Flags: review?(mh+mozilla)
Attachment #664753 - Flags: review?(mh+mozilla)
(In reply to Mike Hommey [:glandium] from comment #15)
> Comment on attachment 662099 [details] [diff] [review]
> Bug 788955 - Prevent pragma visibility from hiding _pthread_mutex_init_calloc_cb on FreeBSD.
...
> Please upstream this.

FWIW, the patch sent to jemalloc-discuss on 18 Sep still waits for moderator approval (from Jason?). Too late to cancel and resend after subscription/registration.
Comment on attachment 664753 [details] [diff] [review]
cumulative

Review of attachment 664753 [details] [diff] [review]:
-----------------------------------------------------------------

::: allmakefiles.sh
@@ +58,5 @@
>      memory/mozalloc/Makefile
>      mozglue/Makefile
>      mozglue/build/Makefile
>    "
> +  if [ "$MOZ_JEMALLOC" -a ! "$MOZ_NATIVE_JEMALLOC" ]; then

-a -z "$MOZ_NATIVE_JEMALLOC"

::: js/src/configure.in
@@ +3109,5 @@
>  
>  MOZ_ALLOCATING_FUNCS="strndup posix_memalign memalign valloc"
>  AC_CHECK_FUNCS(strndup posix_memalign memalign valloc)
>  
> +AC_CHECK_FUNCS(malloc_usable_size)

Neither HAVE_MALLOC_USABLE_SIZE nor MALLOC_H are used in js/src, you can drop these changes.
In fact, the whole block about allocation headers/functions can be removed (that can be done in a separate bug)

::: memory/build/extraMallocFuncs.c
@@ +106,3 @@
>  /* Override some jemalloc defaults */
> +#if defined(MOZ_NATIVE_JEMALLOC)
> +MOZ_EXTERNAL_VIS

MOZ_EXTERNAL_VIS is an implementation detail of MOZ_EXPORT_API/MOZ_EXPORT_DATA, it's better not to use it.
Just use MOZ_EXPORT_DATA unconditionally here.

@@ +118,5 @@
>    __android_log_print(ANDROID_LOG_INFO, "GeckoJemalloc", "%s", s);
>  }
>  
> +#if defined(MOZ_NATIVE_JEMALLOC)
> +MOZ_EXTERNAL_VIS

I doubt we'll ever have native jemalloc for android. Please drop this.

::: memory/build/mozjemalloc_compat.c
@@ +17,1 @@
>  extern int je_mallctl(const char*, void*, size_t*, void*, size_t);

If mallctl doesn't have a different signature, the include MALLOC_H and this ifndef are not necessary.
Attachment #664753 - Flags: review?(mh+mozilla) → review+
Depends on: 795742
Attachment #663429 - Attachment is obsolete: true
Attached patch cumulative (obsolete) — Splinter Review
(In reply to Mike Hommey [:glandium] from comment #34)
> ::: memory/build/extraMallocFuncs.c
> @@ +106,3 @@
> >  /* Override some jemalloc defaults */
> > +#if defined(MOZ_NATIVE_JEMALLOC)
> > +MOZ_EXTERNAL_VIS
> 
> MOZ_EXTERNAL_VIS is an implementation detail of
> MOZ_EXPORT_API/MOZ_EXPORT_DATA, it's better not to use it.
> Just use MOZ_EXPORT_DATA unconditionally here.

malloc_conf is not implemented here, so MOZ_IMPORT_DATA. And I've switched to wrap() macro. It's more easy on the eyes by being explicit.
Attachment #664753 - Attachment is obsolete: true
Attachment #666360 - Flags: review?(mh+mozilla)
Attached patch cumulative (obsolete) — Splinter Review
missed #undef wrap in jemalloc.h, otherwise it pollutes namespace
Attachment #666360 - Attachment is obsolete: true
Attachment #666360 - Flags: review?(mh+mozilla)
Attachment #666365 - Flags: review?(mh+mozilla)
Attached patch cumulative (obsolete) — Splinter Review
It seems mangling full jemalloc 3.0.0 API on FreeBSD is not needed, only the functions used without je_ prefix and also available in glibc e.g., malloc/free, malloc_usable_size.
Attachment #666365 - Attachment is obsolete: true
Attachment #666365 - Flags: review?(mh+mozilla)
Attachment #666488 - Flags: review?(mh+mozilla)
Comment on attachment 666488 [details] [diff] [review]
cumulative

Can you request review when you're actually done testing/changing it?
Attachment #666488 - Flags: review?(mh+mozilla)
Attached patch cumulativeSplinter Review
fixed another minor mistake - duplicate malloc_usable_size in MANGLE

(In reply to Mike Hommey [:glandium] from comment #38)
> Can you request review when you're actually done testing/changing it?

I do admit having poor self-review for changes that cannot (easily?) be tested:
- wrap() change inspired by MOZ_EXPORT_DATA and existing code in extraMallocFuncs.c, builds/works either way
- jemalloc.h namspace pollution with wrap(), builds/works fine either way
- dup malloc_usable_size in MANGLE, builds/works fine either way
- whether to mangle full jemalloc 3.0.0 API, builds/works either way

Hopefully, this is final unless you have more suggestions. I wanted to update split patches *after* review to slightly reduce bugmail spam but if you insist...
Attachment #666488 - Attachment is obsolete: true
Attachment #666827 - Flags: review?(mh+mozilla)
Attachment #663281 - Attachment is obsolete: true
Doh, `git bz apply 788955' doesn't like offsets when patching. Attaching from a pristine branch this time.
Attachment #666830 - Attachment is obsolete: true
Nah, it still fails to apply.
Attachment #666827 - Flags: review?(mh+mozilla) → review+
Please push to TryServer first in this order:
Bug 795742 - Remove a configure check unused in JS code. r=glandium
Bug 778078 - Disable GLib slice allocator on systems with jemalloc in libc. r=glandium
Bug 788955 - Prevent pragma visibility from hiding _pthread_mutex_init_calloc_cb on FreeBSD. r=glandium
Bug 788955 - Without --enable-jemalloc detect and use jemalloc3 in libc. r=glandium
Bug 788955 - Mark some jemalloc functions as weak on BSDs. r=glandium
Bug 788955 - Mangle system malloc functions on BSDs. r=glandium
Bug 788955 - Check for malloc_usable_size() and malloc_np.h via autoconf. r=glandium
Keywords: checkin-needed
(In reply to Mike Hommey [:glandium] from comment #47)
> With jemalloc:
> https://tbpl.mozilla.org/?tree=Try&rev=309c3d91dc2b

Windows builds fail with an error in extraMallocFuncs.c (without telling what exactly... we have logging problems on windows). The Android and OSX failures are unrelated, but they prevent the patch queue from being actually tested. I'll file bugs for these.
Depends on: 799093
(In reply to Mike Hommey [:glandium] from comment #48)
> The Android and OSX failures are unrelated, but they prevent the patch queue from being actually
> tested.

It was B2G, not Android.
The windows error is:
e:/builds/moz2_slave/try-w32/build/memory/build/extraMallocFuncs.c(106) : error C2491: 'je_malloc_conf' : definition of dllimport data not allowed
(In reply to Mike Hommey [:glandium] from comment #51)
> Testing again with this change:
> https://hg.mozilla.org/try/diff/17afa3dd500d/memory/build/extraMallocFuncs.c
> 
> https://tbpl.mozilla.org/?tree=Try&rev=17afa3dd500d

And that worked. I'd prefer waiting for bug 799093 being fixed before landing this.
(In reply to Mike Hommey [:glandium] from comment #52)
> (In reply to Mike Hommey [:glandium] from comment #51)
> > Testing again with this change:
> > https://hg.mozilla.org/try/diff/17afa3dd500d/memory/build/extraMallocFuncs.c
> > 
> > https://tbpl.mozilla.org/?tree=Try&rev=17afa3dd500d
> 
> And that worked. I'd prefer waiting for bug 799093 being fixed before
> landing this.

OK. The change is now integrated, too.
Attachment #666828 - Attachment is obsolete: true
With the fix for bug 799093, bug 799090 and bug 799425, I get green on b2g and osx with this queue. I will land this bug when jemalloc upstream gets both patches from this bug and bug 799090 applied, at which point i will pull a git snapshot.
Blocks: 762445
https://hg.mozilla.org/mozilla-central/rev/712c7dbe7c28
https://hg.mozilla.org/mozilla-central/rev/b741e9670dd0
https://hg.mozilla.org/mozilla-central/rev/3e0d9ab85a5c
https://hg.mozilla.org/mozilla-central/rev/542a978f042c
Assignee: nobody → jbeich
Status: NEW → RESOLVED
Closed: 12 years ago
Flags: in-testsuite-
Resolution: --- → FIXED
Target Milestone: --- → mozilla19
Comment on attachment 666827 [details] [diff] [review]
cumulative

[Triage Comment]
a-b2g18=me; we need this for bug 804303.
Attachment #666827 - Flags: approval-mozilla-b2g18+
Whiteboard: [status-b2g18:fixed]
Depends on: 827016
You need to log in before you can comment on or make changes to this bug.