The crash is still there in v5.0.0

Renewed summary: The reported memory errors are not just a nuisance without further impact, but cause very easily reproducible crashes. I’ve been running patched versions for months now, and I do consider them a significant improvement. The only strange thing I notice is that line-breaking seems to be non-deterministic somehow. I don't think this is a consequence of this patch. Rather it only surfaces now that the crash that would have occurred without it, is gone. See <https://drive.google.com/file/d/132K0BOvsD9di8wHMMPVyY0g0W822XRsm/view?usp=drive_link>. I cannot find a good justification for some of the lines being considered actual lines, while others seem to be treated as strings of equal length to window width at the time of creation. All of the lines in this screen capture originate from this shell command used to prevent my PVR hard disk from spinning down:

while sleep 240; do date && touch xx; done

The original patch is attached to this bug report here, and the rebased versions are obtainable from the PPA/copr repos linked from my previous comment.

It's a real shame that this patch is still lingering here. I have been plagued by occasional screen crashes since version 4.3.1 in 2015, but I have never been able to reproduce it. It just happened during window resizing from time to time, usually at the most inconvenient moment. Since then, I have been very reluctant to resize windows for fear of screen crashing again, taking all subwindows with it. So I finally attempted to reproduce it just a few weeks ago and gave up without anything to show for it after a few hours. But as luck would have it, and not looking for it actively anymore, I found a relatively reliable reproducer two days ago.

I remember always blaming this fix because it shows up in the git log just before the 4.3.1 release, which is the one that Fedora upgraded its package to at the time, and which introduced me to the entire issue, but now that I have a way to test for it, I found out that it was actually caused by this, which makes sense, because previously, the allocated memory sizes were generously rounded up, so the occasional overflow by 1 byte would not usually cause problems.

The crash looks like this, apparently because of heap corruption:

Program received signal SIGABRT, Aborted.
__pthread_kill_implementation (no_tid=0, signo=6, threadid=140043730262912) at ./nptl/pthread_kill.c:44
44      ./nptl/pthread_kill.c: No such file or directory.
(gdb) bt
#0  __pthread_kill_implementation (no_tid=0, signo=6, threadid=140043730262912) at ./nptl/pthread_kill.c:44
#1  __pthread_kill_internal (signo=6, threadid=140043730262912) at ./nptl/pthread_kill.c:78
#2  __GI___pthread_kill (threadid=140043730262912, signo=signo@entry=6) at ./nptl/pthread_kill.c:89
#3  0x00007f5e78a42476 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#4  0x00007f5e78a287f3 in __GI_abort () at ./stdlib/abort.c:79
#5  0x00007f5e78a896f6 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7f5e78bdbb8c "%s\n")
    at ../sysdeps/posix/libc_fatal.c:155
#6  0x00007f5e78aa0d7c in malloc_printerr (str=str@entry=0x7f5e78bd9711 "corrupted size vs. prev_size")
    at ./malloc/malloc.c:5664
#7  0x00007f5e78aa1862 in unlink_chunk (p=p@entry=0x55cfd4bb4610, av=0x7f5e78c19c80 <main_arena>) at ./malloc/malloc.c:1629
#8  0x00007f5e78aa4cac in _int_realloc (av=av@entry=0x7f5e78c19c80 <main_arena>, oldp=oldp@entry=0x55cfd4bb4580,
    oldsize=oldsize@entry=144, nb=nb@entry=160) at ./malloc/malloc.c:4872
#9  0x00007f5e78aa5989 in __GI___libc_realloc (oldmem=oldmem@entry=0x55cfd4bb4590, bytes=bytes@entry=139)
    at ./malloc/malloc.c:3485
#10 0x000055cfd3d227a5 in xrealloc (len=139, mem=0x55cfd4bb4590 ' ' <repeats 136 times>, "\221") at resize.c:624
#11 CheckMaxSize (wi=wi@entry=138) at resize.c:543
#12 0x000055cfd3d2352d in ChangeScreenSize (wi=138, he=39, change_fore=change_fore@entry=1) at resize.c:182
#13 0x000055cfd3d2371a in CheckScreenSize (change_flag=change_flag@entry=1) at resize.c:143
#14 0x000055cfd3d281b9 in ReceiveMsg () at socket.c:1213
#15 0x000055cfd3d5b878 in sched () at sched.c:222
#16 0x000055cfd3d10708 in main (ac=0, av=<optimized out>) at screen.c:1486

To reproduce it, I run "setarch -RL x86_64 screen" in a moderately-sized (around 100x40) GNOME Terminal window, fetch "less ~/temp/test-resize.csv" from the shell history (Ctrl-R plus a few letters), run it, grab the left window handle and expand the window to around 200 columns. It does not always crash, but it is very unlikely to not crash 5 times in a row. And if it does, it's within the first two seconds of dragging the window around. This is on Ubuntu 22.04 amd64. I am not using a special ~/.screenrc file for this test. The reproducing test file is attached, and it is actually nothing special at all. Just a few lines of numbers.

So I've happily been running a patched v4.9.0 since yesterday without issues (there are some memmoves in the patch that were once bclears, so this needed to be adjusted for the -v4 branch).

(file #55074)

I detected an out of bounds heap read in screen when building with address sanitizer. Happens both in 4.6.2 and current git, though the code changed a bit, so the line numbers differ. I'll attach stack traces for both.

This can be reliably reproduced for me by:
1. compile screen with -fsanitize=address in CFLAGS+LDFLAGS.
2. run screen in a terminal emulator.
3. Press ctrl-a.
4. Resize the window.

Screen will hang and the main process will have crashed with an oob read in MClearArea.

Stack trace:
==19786==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x615000001154 at pc 0x561d8c848842 bp 0x7ffdea718400 sp 0x7ffdea7183f0
READ of size 4 at 0x615000001154 thread T0
    #0 0x561d8c848841 in MClearArea /mnt/ram/screen/src/ansi.c:2117
    #1 0x561d8c8411ab in ClearLineRegion /mnt/ram/screen/src/ansi.c:1636
    #2 0x561d8c8390a8 in DoCSI /mnt/ram/screen/src/ansi.c:887
    #3 0x561d8c834085 in WriteString /mnt/ram/screen/src/ansi.c:426
    #4 0x561d8c937335 in win_readev_fn /mnt/ram/screen/src/window.c:1443
    #5 0x561d8c90ae42 in sched /mnt/ram/screen/src/sched.c:164
    #6 0x561d8c8250f9 in main /mnt/ram/screen/src/screen.c:1075
    #7 0x7f33026c8f85 in __libc_start_main (/lib64/libc.so.6+0x20f85)
    #8 0x561d8c8204a9 in _start (/mnt/ram/screen/src/screen+0x294a9)

0x615000001154 is located 0 bytes to the right of 468-byte region [0x615000000f80,0x615000001154)
allocated by thread T0 here:
    #0 0x7f33033ff220 in realloc (/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/libasan.so.4+0xe1220)
    #1 0x561d8c90640d in xrealloc /mnt/ram/screen/src/resize.c:455
    #2 0x561d8c90503f in CheckMaxSize /mnt/ram/screen/src/resize.c:394
    #3 0x561d8c901cb1 in ChangeScreenSize /mnt/ram/screen/src/resize.c:128
    #4 0x561d8c901518 in CheckScreenSize /mnt/ram/screen/src/resize.c:100
    #5 0x561d8c9150f0 in ReceiveMsg /mnt/ram/screen/src/socket.c:813
    #6 0x561d8c828ee7 in serv_read_fn /mnt/ram/screen/src/screen.c:1627
    #7 0x561d8c90ae42 in sched /mnt/ram/screen/src/sched.c:164
    #8 0x561d8c8250f9 in main /mnt/ram/screen/src/screen.c:1075
    #9 0x7f33026c8f85 in __libc_start_main (/lib64/libc.so.6+0x20f85)