[PATCH 3/3] Improve zone support for OSX

[Mike Hommey]

On Thu, Apr 05, 2012 at 10:52:07AM -0700, Jason Evans wrote:
> On Apr 5, 2012, at 2:45 AM, Mike Hommey wrote:
> > 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?
> 
> There are assertions that catch attempts to free interior pointers for
> small allocations, but as far as I know, freeing interior pointers for
> small allocations will otherwise work.  Freeing interior pointers for
> large and huge allocations will always cause some sort of metadata
> corruption.  I expect that both of your test cases are actually
> causing corruption.  Do you have assertions enabled?  I think (hope)
> there are assertions that will fail in both cases.

You're unfortunately right, with assertions, it fails:
<jemalloc>: ../src/arena.c:1437: Failed assertion: "((uintptr_t)ptr &
PAGE_MASK) == 0"

But I was under the impression that the isvalloc check was
making things safer.

Mike