Re: "crash: free invalid next size (fast)" on completion

["Jun. T" <takimoto-j@xxxxxxxxxxxxxxxxx>]

> 2022/03/24 19:47, Peter Stephenson <p.w.stephenson@xxxxxxxxxxxx> wrote:
> 
>> On 24 March 2022 at 10:12 Johan Ström <johan@xxxxxxxxxxx> wrote:
>> 
>> 1. Execute ls
>> 2. Use up-arrow, triggers warning:
>>  ==2157023== Invalid read of size 32
>> ==2157023==    at 0x4B7709D: __wmemcmp_avx2_movbe (in /usr/lib/libc.so.6)
>> ==2157023==    by 0x5863FDC: mkundoent (in /usr/lib/zsh/5.8.1/zsh/zle.so)
>> ...
>> ==2157023==  Address 0x5c2de50 is 0 bytes inside a block of size 8 alloc'd
>> ==2157023==    at 0x484ACD3: realloc (in 
>> /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
>> ==2157023==    by 0x586404F: setlastline (in /usr/lib/zsh/5.8.1/zsh/zle.so)

I can reproduce this on the latest Arch (glibc-2.35) and Fedora-35 (glibc-2.34),
but not on Fedora-34 (glibc-2.33) or Ubuntu-20.04 (glibc-2.31).

> From circumstantial evidence, I'm guessing that might go away with the following?

No, valgrind still reports it on Arch and Fedora-35.
But I think this is a false positive and we can ignore it.

If I run the following program under valgrind (on Arch/Fedora-35), I get
the same 'Invalid read of size 32' error. I've sent a bug report to valgrind
bug tracker, but haven't got any response yet.

#include <stdlib.h>
#include <wchar.h>
int main()  {
    wchar_t *a, *b;
    int ret;
    a = (wchar_t*)calloc(3, sizeof(wchar_t));
    b = (wchar_t*)calloc(3, sizeof(wchar_t));
    ret = wmemcmp(a, b, 2);
    free(a);
    free(b);
    return ret;
}