contour: "Calculated current line does not match" followed by assert()

Description

NOTE: i just realized i was using TERM=vte-256color throughout. I’m going to switch to TERM=contour/TERM=contour-latest and try again. Nonetheless, I wouldn’t expect segfaults from improper escape codes, if that’s what was happening.

Running contour from tip of master 2021-04-19 5daf772d99cb17319ee6426df03c6a013d4e27a8 on Compiz 0.8 on Linux 5.11.15, Debian Unstable. I’m the author of Notcurses, a “blingful TUI library”. I was trying out contour by running notcurses-demo from my 2.2.8 release (same behavior with tip of master). During the first demo, intro, I get the following output:

==================================================================================================================================
Calculated current line does not match.
==================================================================================================================================
Rendered screen at the time of failure: 130x64
cursor position      : (64:1, (invis))
vertical margins     : 1..64
horizontal margins   : 1..130
==================================================================================================================================

followed by

contour: ../src/terminal/Screen.cpp:517: void terminal::Screen::fail(const string&) const: Assertion `false' failed.

The same thing happened with most of my other example programs. pixel ../data/warmech.bmp elicited:

==================================================================================================================================
Calculated current line does not match.
==================================================================================================================================
Rendered screen at the time of failure: 130x30
cursor position      : (10:1, (invis))
vertical margins     : 1..30
horizontal margins   : 1..130
==================================================================================================================================

followed by the same assertion failure. Both of these programs were driving Sixels. I then ran a non-Sixel program, and got a straight segfault (zalgo, exercising some complex Unicode):

[schwarzgerat](0) $ valgrind --tool=memcheck src/contour/contour
==511403== Memcheck, a memory error detector
==511403== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==511403== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright info
==511403== Command: src/contour/contour
==511403== 
==511403== Warning: noted but unhandled ioctl 0x5441 with no size/direction hints.
==511403==    This could cause spurious value errors to appear.
==511403==    See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper.
==511403== Warning: unimplemented fcntl command: 1033
==511403== Invalid write of size 4
==511403==    at 0x2F3123: unicode::script_segmenter::mergeSets(unicode::fs_array<unicode::Script, 32ul> const&, unicode::fs_array<unicode::Script, 32ul>&) (script_segmenter.cpp:97)
==511403==    by 0x2F2C31: unicode::script_segmenter::consume() (script_segmenter.cpp:31)
==511403==    by 0x2B8733: unicode::script_segmenter::consume(unicode::out<unsigned long>, unicode::out<unicode::Script>) (script_segmenter.h:57)
==511403==    by 0x2BDC1E: void unicode::basic_run_segmenter<unicode::script_segmenter, unicode::emoji_segmenter>::consumeUntilSplitPosition<unicode::script_segmenter, unicode::Script>(unicode::script_segmenter&, unicode::out<unsigned long>, unicode::out<unicode::Script>) (run_segmenter.h:164)
==511403==    by 0x2BC14B: void unicode::basic_run_segmenter<unicode::script_segmenter, unicode::emoji_segmenter>::consumeAllUntilSplitPosition<0ul, unicode::script_segmenter, unicode::emoji_segmenter>() (run_segmenter.h:143)
==511403==    by 0x2B9AE4: unicode::basic_run_segmenter<unicode::script_segmenter, unicode::emoji_segmenter>::consume(unicode::out<unicode::basic_run_segmenter<unicode::script_segmenter, unicode::emoji_segmenter>::range>) (run_segmenter.h:112)
==511403==    by 0x2B6364: terminal::renderer::TextRenderer::requestGlyphPositions() (TextRenderer.cpp:192)
==511403==    by 0x3700000036: ???
==511403==    by 0x3700000036: ???
==511403==    by 0x3700000036: ???
==511403==    by 0x3700000036: ???
==511403==    by 0x3700000036: ???
==511403==  Address 0x1fff001000 is not stack'd, malloc'd or (recently) free'd
==511403== 
==511403== 
==511403== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==511403==  Access not within mapped region at address 0x1FFF001000
==511403==    at 0x2F3123: unicode::script_segmenter::mergeSets(unicode::fs_array<unicode::Script, 32ul> const&, unicode::fs_array<unicode::Script, 32ul>&) (script_segmenter.cpp:97)
==511403==    by 0x2F2C31: unicode::script_segmenter::consume() (script_segmenter.cpp:31)
==511403==    by 0x2B8733: unicode::script_segmenter::consume(unicode::out<unsigned long>, unicode::out<unicode::Script>) (script_segmenter.h:57)
==511403==    by 0x2BDC1E: void unicode::basic_run_segmenter<unicode::script_segmenter, unicode::emoji_segmenter>::consumeUntilSplitPosition<unicode::script_segmenter, unicode::Script>(unicode::script_segmenter&, unicode::out<unsigned long>, unicode::out<unicode::Script>) (run_segmenter.h:164)
==511403==    by 0x2BC14B: void unicode::basic_run_segmenter<unicode::script_segmenter, unicode::emoji_segmenter>::consumeAllUntilSplitPosition<0ul, unicode::script_segmenter, unicode::emoji_segmenter>() (run_segmenter.h:143)
==511403==    by 0x2B9AE4: unicode::basic_run_segmenter<unicode::script_segmenter, unicode::emoji_segmenter>::consume(unicode::out<unicode::basic_run_segmenter<unicode::script_segmenter, unicode::emoji_segmenter>::range>) (run_segmenter.h:112)
==511403==    by 0x2B6364: terminal::renderer::TextRenderer::requestGlyphPositions() (TextRenderer.cpp:192)
==511403==    by 0x3700000036: ???
==511403==    by 0x3700000036: ???
==511403==    by 0x3700000036: ???
==511403==    by 0x3700000036: ???
==511403==    by 0x3700000036: ???
==511403==  If you believe this happened as a result of a stack
==511403==  overflow in your program's main thread (unlikely but
==511403==  possible), you can try to increase the size of the
==511403==  main thread stack using the --main-stacksize= flag.
==511403==  The main thread stack size used in this run was 8388608.
==511403== 
==511403== HEAP SUMMARY:
==511403==     in use at exit: 61,971,679 bytes in 41,185 blocks
==511403==   total heap usage: 278,637 allocs, 237,452 frees, 5,313,727,825 bytes allocated
==511403== 
==511403== LEAK SUMMARY:
==511403==    definitely lost: 26,148 bytes in 71 blocks
==511403==    indirectly lost: 31,283 bytes in 324 blocks
==511403==      possibly lost: 46,388,796 bytes in 109 blocks
==511403==    still reachable: 15,472,036 bytes in 40,241 blocks
==511403==                       of which reachable via heuristic:
==511403==                         length64           : 2,328 bytes in 42 blocks
==511403==                         newarray           : 1,936 bytes in 41 blocks
==511403==                         multipleinheritance: 104 bytes in 1 blocks
==511403==         suppressed: 0 bytes in 0 blocks
==511403== Rerun with --leak-check=full to see details of leaked memory
==511403== 
==511403== For lists of detected and suppressed errors, rerun with: -s
==511403== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Segmentation fault
[schwarzgerat](139) $ 

Environment

See information above, especially regarding TERM.

Steps to Reproduce

See above. I’m happy to run valgrind/gdb/whatever to help you out, subject to time demands from elsewhere, but we’re all in on this terminal ecosystem together =].