[PATCH 3/3] Improve zone support for OSX
mh+jemalloc at glandium.org
Thu Apr 5 02:45:25 PDT 2012
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 .
> >>  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).
char *ptr = malloc((1 << 15) + 1); free(ptr + 32);
does free the pointer, while
char *ptr = malloc(1 << 15); free(ptr + 32);
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?
More information about the jemalloc-discuss