[Toybox] Release prep.

[Andreas Gampe]

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.

>
>> 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