[PATCH 3/3] Improve zone support for OSX

[Jason Evans]

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.

Thanks,
Jason