dankamongmen
amata_next_string() doesn't look like it's handling 0x07 as a terminator
I think this chunk of code allows a string terminator of ST or BEL:
https://github.com/dankamongmen/notcurses/blob/3a3c75e65ac8342f10a0e16eb63ab642aaf52ef4/src/lib/automaton.c#L560-L563
However, the amata_next_string() only looks for the escape:
https://github.com/dankamongmen/notcurses/blob/3a3c75e65ac8342f10a0e16eb63ab642aaf52ef4/src/lib/in.c#L446-L452
I think things usually work because there is another escape sequence following the one currently being processed. So, amata_next_kleene() skips over the BEL and hits the escape in the next sequence. However, if something like a palette response comes at the very end of the buffer, amata_next_kleene() will run past the end of the buffer. Here are some of the debug logs with an ASAN backtrace when this happened on a run:
2024-12-11T21:35:34.237-08:00 E t4 lnav_log.cc:674 process_melange:2381:input 988 (0)/26 [0x1b] ( )
process_escape:2227:walk result on 93 (]): 0 431
process_escape:2227:walk result on 52 (4): 0 451
2024-12-11T21:35:34.237-08:00 E t4 lnav_log.cc:674 process_escape:2227:walk result on 59 (;): 0 452
process_escape:2227:walk result on 56 (8): 0 453
process_escape:2227:walk result on 56 (8): 0 453
2024-12-11T21:35:34.237-08:00 E t4 lnav_log.cc:674 process_escape:2227:walk result on 59 (;): 0 454
process_escape:2227:walk result on 114 (r): 0 455
process_escape:2227:walk result on 103 (g): 0 456
2024-12-11T21:35:34.237-08:00 E t4 lnav_log.cc:674 process_escape:2227:walk result on 98 (b): 0 457
process_escape:2227:walk result on 58 (:): 0 458
process_escape:2227:walk result on 56 (8): 0 459
2024-12-11T21:35:34.237-08:00 E t4 lnav_log.cc:674 process_escape:2227:walk result on 55 (7): 0 459
process_escape:2227:walk result on 56 (8): 0 459
process_escape:2227:walk result on 55 (7): 0 459
2024-12-11T21:35:34.237-08:00 E t4 lnav_log.cc:674 process_escape:2227:walk result on 47 (/): 0 459
process_escape:2227:walk result on 48 (0): 0 459
process_escape:2227:walk result on 48 (0): 0 459
2024-12-11T21:35:34.237-08:00 E t4 lnav_log.cc:674 process_escape:2227:walk result on 48 (0): 0 459
process_escape:2227:walk result on 48 (0): 0 459
process_escape:2227:walk result on 47 (/): 0 459
2024-12-11T21:35:34.237-08:00 E t4 lnav_log.cc:674 process_escape:2227:walk result on 48 (0): 0 459
process_escape:2227:walk result on 48 (0): 0 459
process_escape:2227:walk result on 48 (0): 0 459
2024-12-11T21:35:34.237-08:00 E t4 lnav_log.cc:674 process_escape:2227:walk result on 48 (0): 0 459
2024-12-11T21:35:34.237-08:00 E t4 lnav_log.cc:674 =================================================================
2024-12-11T21:35:34.237-08:00 E t4 lnav_log.cc:674 ==96908==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61e00006e238 at pc 0x0001080feb64 bp 0x00016b5da110 sp 0x00016b5da108
2024-12-11T21:35:34.237-08:00 E t4 lnav_log.cc:674 READ of size 1 at 0x61e00006e238 thread T5
2024-12-11T21:35:34.237-08:00 E t4 lnav_log.cc:674 #0 0x1080feb60 in amata_next_kleene in.c:400
#1 0x1080fed9c in amata_next_string in.c:452
#2 0x1080f96f0 in palette_cb in.c:1486
#3 0x1080c2f44 in walk_automaton automaton.c:569
#4 0x1080ec748 in process_escape in.c:2225
#5 0x1080e5654 in process_melange in.c:2384
#6 0x1080f13f4 in process_ibuf in.c:2438
#7 0x1080e7afc in input_thread in.c:2648
#8 0x10eda1858 in asan_thread_start(void*)+0x40 (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x51858)
#9 0x19346b2e0 in _pthread_start+0x84 (libsystem_pthread.dylib:arm64e+0x72e0)
#10 0x1934660f8 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x20f8)
2024-12-11T21:35:34.237-08:00 E t4 lnav_log.cc:674 0x61e00006e238 is located 0 bytes after 2488-byte region [0x61e00006d880,0x61e00006e238)
2024-12-11T21:35:34.237-08:00 E t4 lnav_log.cc:674 allocated by thread T0 here:
2024-12-11T21:35:34.237-08:00 E t4 lnav_log.cc:674 #0 0x10eda4c04 in malloc+0x94 (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x54c04)
#1 0x1080e60e0 in create_inputctx in.c:1939
#2 0x1080e5e64 in init_inputlayer in.c:2656
#3 0x10819e688 in interrogate_terminfo termdesc.c:1383
#4 0x10812e37c in notcurses_core_init notcurses.c:1350
#5 0x1074112c4 in screen_curses::create(notcurses_options const&) view_curses.cc:1295
#6 0x104c3e364 in looper() lnav.cc:1230
#7 0x104c18794 in main lnav.cc:3699
#8 0x1930e8270 (<unknown module>)
(There's some extra crud from my own logging. Note that the notcurses line numbers won't line up with top-of-tree since I've made some changes)
