Re: printf family handling of INT_MAX +1 tested on aarch64

[CM Graff <cm0graff@gmail.com>]

Rich,
Ah you are right. Sorry about that. My test is off by one.
Graff

On 11/7/18, Rich Felker <dalias@libc.org> wrote:
> On Wed, Nov 07, 2018 at 02:54:02PM -0600, CM Graff wrote:
>> RIch,
>> It just produces a segfault on debian aarch64 in my test case. Whereas
>> INTMAX + 2 does not. So I thought it worth reporting.
>>
>> graff@hlib-debian-arm:~/hlibc-test/tests-emperical/musl$
>> ../usr/bin/musl-gcc ../printf_overflow.c
>> graff@hlib-debian-arm:~/hlibc-test/tests-emperical/musl$
>> ../usr/bin/musl-gcc -static ../printf_overflow.c
>> graff@hlib-debian-arm:~/hlibc-test/tests-emperical/musl$ ./a.out >
>> logfile
>> Segmentation fault
>> graff@hlib-debian-arm:~/hlibc-test/tests-emperical/musl$ uname -a
>> Linux hlib-debian-arm 4.9.0-8-arm64 #1 SMP Debian 4.9.110-3+deb9u6
>> (2018-10-08) aarch64 GNU/Linux
>> graff@hlib-debian-arm:~/hlibc-test/tests-emperical/musl$
>>
>> I can supply access to the 96 core 124 GB RAM aarch64 debian test box
>> if it would help reproduce the segfault. Just email me a public key if
>> you want access.
>
> The failure has nothing to do with printf. You're calling malloc(i)
> then writing to s[i], which is one past the end of the allocated
> buffer. I failed to notice this because you're only writing i-1 A's to
> the buffer, and there already happens to be a nul byte at s[i-1] to
> terminate them.
>
> Actually the crash has nothing to do with aarch64 vs x86_64 but rather
> static vs dynamic linking. With dynamic linking, full malloc is used
> and there happens to be padding space at the end of the allocation
> because there was a header at the beginning and it has to be rounded
> up to whole pages. But with static linking, simple_malloc (a bump
> allocator) was used, and there are exactly i bytes in the allocation.
>
> Fix the s[i]=0 to be s[i-1]=0 instead and the test works as expected.
> And please, when reporting crashes like this, at least try to identify
> where the crash is occurring (e.g. with gdb or even just some trivial
> printf debugging).
>
> Rich
>