742554 - Re-enable jemalloc on OSX x86 and 10.5

Status: RESOLVED INVALID

(Core :: Memory Allocator, defect)

Description

[Mike Hommey [:glandium]]

It looks like bug 702250 is not reproducible anymore on a build with jemalloc forcibly enabled on a machine where it is reproducible with the build it was reported against.
It sounds like it was a bug on our end that triggered it, and that this bug was fixed. Let's re-enable jemalloc and see how things go on crash reports.

Comment 1

[Mike Hommey [:glandium]]

Attachment: Re-enable jemalloc on OSX 10.5 and x86

Note the 10.4 test to avoid breaking TenFourFox. (10.4 had a totally different malloc_zone_t, iirc)

Comment 2

[Mike Hommey [:glandium]]

Pushed to try:
https://tbpl.mozilla.org/?tree=Try&rev=ab8953cabd85

Comment 3

[Justin Lebar (not reading bugmail)]

Comment on attachment 612362 [details] [diff] [review]
Re-enable jemalloc on OSX 10.5 and x86

>  * For OSX 10.8 and later, we may expect the malloc_zone_t struct to change
>- * again, and need to dynamically account for this. By simply leaving
>- * malloc_zone_t alone, we don't quite deal with the problem, because there
>- * remain calls to jemalloc through the mozalloc interface. We check this
>- * dynamically on each allocation, using the CHECK_DARWIN macro and
>- * osx_use_jemalloc.
>- *
>+ * again, and need to dynamically account for this.

This doesn't make a ton of sense anymore.  In what way might we dynamically
account for 10.8?  We stripped out the whole dynamic check...

> 	/*
>-	 * We only use jemalloc with MacOS 10.6 and 10.7.  jemalloc is disabled
>-	 * on 32-bit builds (10.5 and 32-bit 10.6) due to bug 702250, an
>-	 * apparent MacOS bug.  In fact, this code isn't even compiled on
>-	 * 32-bit builds.
>-	 *
> 	 * We'll have to update our code to work with newer versions, because
> 	 * the malloc zone layout is likely to change.
> 	 */

Newer versions of what?

It would be awesome if this worked!

Comment 4

[Mike Hommey [:glandium]]

Bad news... I could reproduce with the try build :(

Comment 5

[Mike Hommey [:glandium]]

It is very much possible that I screwed up in the first place, and the build I tested the first time didn't actually have jemalloc enabled :(
However, I do fail to reproduce with a build with jemalloc2. It would be interesting to check why.

Comment 6

[Justin Lebar (not reading bugmail)]

> However, I do fail to reproduce with a build with jemalloc2. It would be interesting to check why.

From the jemalloc mailing list, it sounds like jemalloc2 may be robust to bogus pointers like this?  I don't even care if it doesn't free the pointer, so long as it doesn't crash.  But I suspect you were somehow getting lucky, and that jemalloc is not in general robust to invalid pointers.