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

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

[Johan Ström]

Hi,

On 2022-03-23 18:14, Bart Schaefer wrote:
> (Following up to zsh-users so this thread doesn't appear abandoned;
> further discussion should probably be directed to
> zsh-workers@zsh.org.)
Continuing on zsh-worker
>
> On Tue, Mar 22, 2022 at 12:41 AM Johan Ström <johan@stromnet.se> wrote:
>> last week (and now today again, on several terminals after being idle since Friday) I noticed that several of my terminals crashed and closed when writing `git <tab>` or `ls <tab>`. Managed to capture one such crash on video before terminal closed, and it printed "free invalid next size (fast)".

> ...
>>                  Stack trace of thread 843836:
>>                  #5  0x00007f36842f104d _int_free (libc.so.6 + 0x9b04d)
>>                  #6  0x00007f36842f3be3 free (libc.so.6 + 0x9dbe3)
>>                  #7  0x00007f36839ffa7f unmetafy_line (zle.so + 0x33a7f)
>>                  #8  0x00007f3683a0427a n/a (zle.so + 0x3827a)
>>                  #9  0x00007f36839fcc34 completecall (zle.so + 0x30c34)
>>
>> These terminals have been running for ~5 days.
>> On newly opened terminals, tab completion works fine.
>>
>> Have had 5.8-1 on this machine since July, never had any issues. 5.8.1-1 installed on 16 Feb.
> Hm.  There's nothing in the zsh code changes I see that would cause
> this effect; an actually idle shell should have been sitting blocked
> on read.  Is there any sort of periodic event that might be sending a
> signal to those shells?

There is nothing in my .zsh config that I'm aware of that would do 
anything periodic. PS1 is simple: "%m %~$". The terminal is foot 
(https://codeberg.org/dnkl/foot) and window manager is sway 
(wlroots-based), not sure if they'd do anything.. The terminal was 
seemingly identical to how I left it at least.
A bunch of other packages have been updated at the same time, so could 
of course be something external. But I have not experienced any crashes 
or issues in any other programs.

Took a quick look on the 5.8..5.8.1 diff and there seems to be some 
buffer juggling going on, didn't look too close but perhaps there is 
some overflow or double free or something?

>
> Do other completions crash, or only completions that involve file names?
Not sure, will check with some known completion if I see it again 
(typically have a bunch of terminal open, and at least previously 
multiple of them seemed to break)

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

[Peter Stephenson]

> On 24 March 2022 at 07:31 Johan Ström <johan@stromnet.se> wrote:
> > Do other completions crash, or only completions that involve file names?
> Not sure, will check with some known completion if I see it again 
> (typically have a bunch of terminal open, and at least previously 
> multiple of them seemed to break)

Could you leave something running with "valgrind zsh" and see if that crashes
and gives a bit more information?

Like Bart I'm hard pressed to work out what might be going on while it's
idle, but it does look like the corruption has already happened when you
come back to it.

pws

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

[Johan Ström]

On 2022-03-24 10:58, Peter Stephenson wrote:
>> On 24 March 2022 at 07:31 Johan Ström <johan@stromnet.se> wrote:
>>> Do other completions crash, or only completions that involve file names?
>> Not sure, will check with some known completion if I see it again
>> (typically have a bunch of terminal open, and at least previously
>> multiple of them seemed to break)
> Could you leave something running with "valgrind zsh" and see if that crashes
> and gives a bit more information?
>
> Like Bart I'm hard pressed to work out what might be going on while it's
> idle, but it does look like the corruption has already happened when you
> come back to it.
>
> pws

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==    by 0x5865555: handleundo (in /usr/lib/zsh/5.8.1/zsh/zle.so)
==2157023==    by 0x58516F1: zlecore (in /usr/lib/zsh/5.8.1/zsh/zle.so)
==2157023==    by 0x5852586: zleread (in /usr/lib/zsh/5.8.1/zsh/zle.so)
==2157023==    by 0x1738A2: zleentry (in /usr/bin/zsh)
==2157023==    by 0x1741AC: ingetc (in /usr/bin/zsh)
==2157023==    by 0x166A93: ??? (in /usr/bin/zsh)
==2157023==    by 0x1824CE: ??? (in /usr/bin/zsh)
==2157023==    by 0x1A6F87: parse_event (in /usr/bin/zsh)
==2157023==    by 0x16CC4D: loop (in /usr/bin/zsh)
==2157023==    by 0x175A34: zsh_main (in /usr/bin/zsh)
==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)
==2157023==    by 0x5849799: zle_setline (in /usr/lib/zsh/5.8.1/zsh/zle.so)
==2157023==    by 0x5849F10: zle_goto_hist (in 
/usr/lib/zsh/5.8.1/zsh/zle.so)
==2157023==    by 0x5849F5A: uphistory (in /usr/lib/zsh/5.8.1/zsh/zle.so)
==2157023==    by 0x5849FDC: uplineorhistory (in 
/usr/lib/zsh/5.8.1/zsh/zle.so)
==2157023==    by 0x584F265: execzlefunc (in /usr/lib/zsh/5.8.1/zsh/zle.so)
==2157023==    by 0x585183B: zlecore (in /usr/lib/zsh/5.8.1/zsh/zle.so)
==2157023==    by 0x5852586: zleread (in /usr/lib/zsh/5.8.1/zsh/zle.so)
==2157023==    by 0x1738A2: zleentry (in /usr/bin/zsh)
==2157023==    by 0x1741AC: ingetc (in /usr/bin/zsh)
==2157023==    by 0x166A93: ??? (in /usr/bin/zsh)
==2157023==

Using up/down arrows a bit triggers the same thing again, but after a 
few ups/downs it stops. Can reproduce 100% it seems.

Will leave valgrinds running.

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

[Peter Stephenson]

> On 24 March 2022 at 10:12 Johan Ström <johan@stromnet.se> 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;
     }

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

[Jun. T]

> 2022/03/24 19:47, Peter Stephenson <p.w.stephenson@ntlworld.com> wrote:
> 
>> On 24 March 2022 at 10:12 Johan Ström <johan@stromnet.se> 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;
}

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

[Bart Schaefer]

On Thu, Mar 31, 2022 at 10:18 AM Jun. T <takimoto-j@kba.biglobe.ne.jp> wrote:
>
> No, valgrind still reports it on Arch and Fedora-35.
> But I think this is a false positive and we can ignore it.

That leaves the original crash unsolved, though.