[Toybox] Release prep.

[enh]

On Fri, Feb 9, 2018 at 9:07 AM, Andreas Gampe <agampe at google.com> wrote:
> On Fri, Feb 9, 2018 at 7:36 AM, Rob Landley <rob at landley.net> wrote:
>>
>>
>> On 02/08/2018 10:44 AM, Andreas Gampe wrote:
>>> Argh. I should have given you the full failure message (or be more
>>> explicit in the suggested solution) - sorry, my mistake. ASAN
>>> complains about a heap buffer overflow, not a null pointer access
>>> (which should always kill top, not just under ASAN). Your fix was:
>>>
>>>   struct carveup *otb = old.tb ? *old.tb : 0, *ntb = new.tb ? *new.tb : 0;
>>
>> Bionic also does the "return non-null for malloc(0);" thing from glibc?
>> I did not know that. (It was a build-time config option back in uclibc.)
>
> That certainly sounds like one of the failure cases. I have to admit
> that I was rather afraid of the counts not starting out equal (but
> both non-zero), but I didn't have the time to trace the code to see
> whether that's possible.

(Andreas reports that the asan build's boot tests have been green
since this change merged in.)

>>> That only works if the tb value started out as null (as the loop
>>> itself only increments the pointers). That doesn't seem to be the
>>> failure case that ASAN is complaining about.
>>
>> ASAN failure, not segfault. Got it.
>>
>>> I think this would be a better solution:
>>>
>>>   struct carveup *otb = old.count ? *old.tb : 0, *ntb = new.count ? *new.tb : 0;
>>
>> Applied.
>>
>> (Sorry, buried at work. I switched to a hopefully less life-eating job
>> at the start of the year, but it's still a new job in a new city with a
>> new apartment and new issues like snow-modulated parking regulations I'm
>> driving my old car back to my house in texas this weekend to avoid. I
>> have yet to have a free weekend since I got here, but have high hopes
>> for next month...)
>>
>> Thanks for following through on this, sorry it was broken.
>>
>> Rob
>
> Thanks for your hard work, Rob! Hope your life settles down a bit soon. :-)
>
> Best,
>  Andreas