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

[Peter Stephenson <p.w.stephenson@xxxxxxxxxxxx>]

> On 24 March 2022 at 10:12 Johan Ström <johan@xxxxxxxxxxx> wrote:
> Launched one now. Quickly noticed this:
> 
> 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)

From circumstantial evidence, I'm guessing that might go away with the following?
Unless there's some reason lastlinesz would not be as long as the allocation of
lastline, it's hard to see how this could be wrong (famous last words).

pws

diff --git a/Src/Zle/zle_utils.c b/Src/Zle/zle_utils.c
index c85f8450d..526216fa7 100644
--- a/Src/Zle/zle_utils.c
+++ b/Src/Zle/zle_utils.c
@@ -1530,7 +1530,7 @@ mkundoent(void)
     struct change *ch;
 
     UNMETACHECK();
-    if(lastll == zlell && !ZS_memcmp(lastline, zleline, zlell)) {
+    if(lastll == zlell && lastlinesz >= zlell && !ZS_memcmp(lastline, zleline, zlell)) {
 	lastcs = zlecs;
 	return;
     }