Crash when resizing window

[ralight]

Hi there,

I've just run across a reproducible crash when running hexedit 1.5-2 on kubuntu 21.04. I ran hexedit <file> in konsole, where the terminal was around 232x61 characters in size. I then resized the window to be smaller using the bottom right hand corner handle (i.e. in both x and y) and hexedit crashed. It doesn't crash consistently when doing this, my impression is that if I resize slowly at the beginning then I can later resize the window as much and as quickly as I want, but I could be mistaken. If I resize quickly it is more likely to crash. I typically find it easier to reproduce using a circular resizing motion.

I've reproduced with two files, one around 9000 bytes and the other >600,000 bytes.

I've attached a video showing me doing this: https://user-images.githubusercontent.com/79578/121201333-5ac7d180-c86c-11eb-8220-3f294569e7f3.mp4

And this is the valgrind log from a different run:

Memcheck, a memory error detector
Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
Using Valgrind-3.17.0 and LibVEX; rerun with -h for copyright info
Command: hexedit vglog
Parent PID: 9995

Invalid read of size 4 
   at 0x10B53B: displayLine (display.c:222)
   by 0x10B98B: display (display.c:189)
   by 0x10A8FC: main (hexedit.c:104)
 Address 0x507a940 is 0 bytes after a block of size 10,560 alloc'd
   at 0x4A43DAD: realloc (vg_replace_malloc.c:1192)
   by 0x10B1F4: initDisplay (display.c:172)
   by 0x10BC83: handleSigWinch (display.c:113)
   by 0x4D0903F: ??? (in /usr/lib/x86_64-linux-gnu/libc-2.33.so)
   by 0x4C7780F: ??? (in /usr/lib/x86_64-linux-gnu/libncurses.so.6.2)
   by 0x4C78FD0: ??? (in /usr/lib/x86_64-linux-gnu/libncurses.so.6.2)
   by 0x4C7A243: waddnstr (in /usr/lib/x86_64-linux-gnu/libncurses.so.6.2)
   by 0x4C83D4C: printw (in /usr/lib/x86_64-linux-gnu/libncurses.so.6.2)
   by 0x10B50C: displayLine (display.c:224)
   by 0x10B98B: display (display.c:189)
   by 0x10A8FC: main (hexedit.c:104)

Invalid write of size 1 
   at 0x4D504CB: __vsnprintf_internal (vsnprintf.c:117)
   by 0x4C89A83: ??? (in /usr/lib/x86_64-linux-gnu/libncurses.so.6.2)
   by 0x4C83C74: vw_printw (in /usr/lib/x86_64-linux-gnu/libncurses.so.6.2)
   by 0x4C83D4C: printw (in /usr/lib/x86_64-linux-gnu/libncurses.so.6.2)
   by 0x10B50C: displayLine (display.c:224)
   by 0x10B98B: display (display.c:189)
   by 0x10A8FC: main (hexedit.c:104)
 Address 0x4f00d62 is 2 bytes inside a block of size 13,787 free'd
   at 0x4A43DAD: realloc (vg_replace_malloc.c:1192)
   by 0x4CAA437: _nc_doalloc (in /usr/lib/x86_64-linux-gnu/libtinfo.so.6.2)
   by 0x4C89A59: ??? (in /usr/lib/x86_64-linux-gnu/libncurses.so.6.2)
   by 0x4C83C74: vw_printw (in /usr/lib/x86_64-linux-gnu/libncurses.so.6.2)
   by 0x4C83D4C: printw (in /usr/lib/x86_64-linux-gnu/libncurses.so.6.2)
   by 0x10B40B: displayLine (display.c:220)
   by 0x10B98B: display (display.c:189)
   by 0x4D0903F: ??? (in /usr/lib/x86_64-linux-gnu/libc-2.33.so)
   by 0x4D56158: _IO_default_xsputn (genops.c:389)
   by 0x4D56158: _IO_default_xsputn (genops.c:370)
   by 0x4D3CD7A: outstring_func (vfprintf-internal.c:239)
   by 0x4D3CD7A: __vfprintf_internal (vfprintf-internal.c:1646)
   by 0x4D504B9: __vsnprintf_internal (vsnprintf.c:114)
   by 0x4C89A83: ??? (in /usr/lib/x86_64-linux-gnu/libncurses.so.6.2)
 Block was alloc'd at
   at 0x4A3EFB5: malloc (vg_replace_malloc.c:380)
   by 0x4C89A59: ??? (in /usr/lib/x86_64-linux-gnu/libncurses.so.6.2)
   by 0x4C83C74: vw_printw (in /usr/lib/x86_64-linux-gnu/libncurses.so.6.2)
   by 0x4C83D4C: printw (in /usr/lib/x86_64-linux-gnu/libncurses.so.6.2)
   by 0x10B40B: displayLine (display.c:220)
   by 0x10B98B: display (display.c:189)
   by 0x10A8FC: main (hexedit.c:104)

Invalid read of size 4 
   at 0x10B441: displayLine (display.c:224)
   by 0x10B98B: display (display.c:189)
   by 0x10A8FC: main (hexedit.c:104)
 Address 0x5733570 is 224 bytes inside an unallocated block of size 11,376 in arena "client"

Invalid read of size 4 
   at 0x10B4EF: displayLine (display.c:224)
   by 0x10B98B: display (display.c:189)
   by 0x10A8FC: main (hexedit.c:104)
 Address 0x5733570 is 224 bytes inside an unallocated block of size 11,376 in arena "client"

Invalid read of size 1 
   at 0x10B4F9: displayLine (display.c:224)
   by 0x10B98B: display (display.c:189)
   by 0x10A8FC: main (hexedit.c:104)
 Address 0x572ad98 is 8 bytes inside an unallocated block of size 28,896 in arena "client"

Invalid read of size 4 
   at 0x10B5D3: displayLine (display.c:222)
   by 0x10B98B: display (display.c:189)
   by 0x10A8FC: main (hexedit.c:104)
 Address 0x5733574 is 228 bytes inside an unallocated block of size 11,376 in arena "client"

Invalid read of size 1 
   at 0x10B68E: displayLine (display.c:240)
   by 0x10B98B: display (display.c:189)
   by 0x10A8FC: main (hexedit.c:104)
 Address 0x572ad74 is 28 bytes before an unallocated block of size 28,896 in arena "client"

Invalid read of size 4 
   at 0x10B699: displayLine (display.c:240)
   by 0x10B98B: display (display.c:189)
   by 0x10A8FC: main (hexedit.c:104)
 Address 0x57334e0 is 80 bytes inside an unallocated block of size 11,376 in arena "client"

Invalid read of size 4 
   at 0x10B74D: displayLine (display.c:241)
   by 0x10B98B: display (display.c:189)
   by 0x10A8FC: main (hexedit.c:104)
 Address 0x57334e0 is 80 bytes inside an unallocated block of size 11,376 in arena "client"

[rsaxvc]

I was unaware of signal-unsafe functions when I added sigwinch support. I think we'll need to defer most of the sigwinch handler until we can redraw outside of the handler. We may also need to sigprocmask sigwinch so that the handler is deferred as well.

[rsaxvc]

It looks like we can, and should probably, just have NCURSES handle this for us and emit a KEY_RESIZE instead. Could you give the linked commit a try?

[ralight]

I've not managed to make it crash with that commit, and valgrind doesn't report any errors either when I use it.

[eribertomota]

@rsaxvc, could you send a PR to pixe/hexedit? This is important to fix the next release in Debian.

[rsaxvc]

Sent. I also retested it on Debian10, but it never failed there before or after for me.

[eribertomota]

Sent. I also retested it on Debian10, but it never failed there before or after for me.

Thanks. Maybe it fails in Debian 11 and above.