[PATCH 3/3] Improve zone support for OSX

[Mike Hommey]

On Tue, Mar 20, 2012 at 01:18:13PM -0400, Justin Lebar wrote:
> On Tue, Mar 20, 2012 at 1:10 PM, Mike Hommey <mh+jemalloc at glandium.org> wrote:
> > On Tue, Mar 20, 2012 at 01:04:54PM -0400, Justin Lebar wrote:
> >> btw, I'm skeptical of the value of supporting OSX 10.5, because 10.5
> >> occasionally passes invalid pointers to ozone_size [1].
> >>
> >> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=694335
> >
> > For one, not all jemalloc users are going to have the problem, which is
> > limited to some APIs.
> 
> True, but we of course don't know the full set of circumstances under
> which OSX will pass an invalid pointer.
> 
> > Also, AIUI, the current jemalloc code does the right thing for the
> > ozone_size, which is not the case in the old jemalloc fork we use in
> > Firefox, so depending on what is done with the result of ozone_size,
> > it might be okay.
> 
> What's the difference in behavior?
> 
> > BTW, I guess you wanted to point to
> > https://bugzilla.mozilla.org/show_bug.cgi?id=702250#c30
> 
> Yes, thanks.  And my analysis there is that 10.5 tries to free the
> internal pointer.  I'd be impressed if jemalloc handled this
> correctly!  (And even more impressed if it worked in general, for
> non-huge allocations too.  :)

>From my trivial testing, it actually works for allocations > (1 << 15).

That is:
char *ptr = malloc((1 << 15) + 1); free(ptr + 32);
does free the pointer, while
char *ptr = malloc(1 << 15); free(ptr + 32);
doesn't.

Neither crash (which is better than the crash we get with our fork :) )

Jason, how actually safe is jemalloc now, when trying to free a pointer
inside an allocation it gave out?

Mike