Re: 13.0-RC3 bison causes tputs SIGSEGV

On Tue, Mar 30, 2021 at 08:48:03PM -0400, Thomas Dickey wrote:
> On Tue, Mar 30, 2021 at 08:37:22AM +0200, Juraj Lutter wrote:
> > Hi,
> > 
> > very similar behavior is observed in editors/poke, on recent 13.0-STABLE (stable/13-85ad493677a2):
> > 
> > (lldb) bt
> > * thread #1, name = 'poke', stop reason = signal SIGSEGV: invalid address (fault address: 0x0)
> >   * frame #0: 0x0000000000000000
> >     frame #1: 0x00000008009ed30a libncursesw.so.9`delay_output_sp(sp=0x0000000000000000, ms=<unavailable>) at lib_tputs.c:104:6
> 
> The SCREEN pointer sp is null here: which could occur if there was
> no matching terminal description.  I noticed that libtextstyle doesn't
> give up on that error, but just proceeds along as though other functions
> which would return the terminal capabilities will somehow return valid
> data when the terminal database isn't initialized.
> 
> >     frame #2: 0x00000008009edb81 libncursesw.so.9`tputs_sp [inlined] delay_output(ms=<unavailable>) at lib_tputs.c:116:12
> >     frame #3: 0x00000008009edb72 libncursesw.so.9`tputs_sp(sp=<unavailable>, string="", affcnt=1, outc=<unavailable>) at lib_tputs.c:422
> >     frame #4: 0x00000008009edcfb libncursesw.so.9`tputs(string="4f0fdc740005bebaf92e5a2e00000000", affcnt=1, outc=(libtextstyle.so.0`out_char at term-ostream.oo.c:1198)) at lib_tputs.c:444:12
> 
> well yes...  The caller is supposed to provide outch via tputs, 
> which isn't a parameter of delay_output (but delay_output needs it).
> ncurses saves/restores that pointer in the SCREEN structure --
> if it's initialized -- otherwise in a static structure.  It's made
> a little more complicated since some paths use stdout and others
> use ncurses' buffering via outch (which may be unrelated to stdout).
> 
> That pointer-juggling dates back to late 2009 -- but of course other
> changes have occurred since then.
> 
> So... the question I have is what is $TERM in this case,
> and where is the related terminal description (in terminfo or termcap).

In the example in my original email, $TERM was "xterm-256color"
(connected through "Windows Terminal" running MS' ssh on Win10).

> 
> Knowing that would help me see whether the problem is faulty initialization
> from libtextstyle (i.e., the SCREEN pointer is null, making the path via
> the static structure), or some ifdef-combination in ncurses that I've
> neglected (i.e., a flaw in the pointer juggling).
> 
> >     frame #5: 0x0000000800424bb0 libtextstyle.so.0`out_hyperlink_change(stream=0x0000000800e3d000, new_hyperlink=0x00000008018bd600, async_safe=false) at term-ostream.oo.c:1586:7
> >     frame #6: 0x000000080042579c libtextstyle.so.0`out_attr_change(stream=0x0000000800e3d000, new_attr=attributes_t _at_ 0x00007fffffffe608) at term-ostream.oo.c:1737:11
> >     frame #7: 0x0000000800424f3b libtextstyle.so.0`output_buffer(stream=0x0000000800e3d000, goal_attr=attributes_t _at_ 0x00007fffffffe690) at term-ostream.oo.c:1906:11
> >     frame #8: 0x00000008004223b2 libtextstyle.so.0`term_ostream__write_mem(stream=0x0000000800e3d000, data=0x0000000000207a94, len=123) at term-ostream.oo.c:2037:11
> >     frame #9: 0x0000000800422ed5 libtextstyle.so.0`term_ostream_write_mem(first_arg=0x0000000800e3d000, data=0x0000000000207a94, len=123) at term-ostream.c:2721:3
> >     frame #10: 0x0000000800427e3f libtextstyle.so.0`term_styled_ostream__write_mem(stream=0x0000000800e3a000, data=0x0000000000207a94, len=123) at term-styled-ostream.oo.c:95:3
> >     frame #11: 0x0000000800420535 libtextstyle.so.0`ostream_write_mem(first_arg=0x0000000800e3a000, data=0x0000000000207a94, len=123) at ostream.c:138:3
> >     frame #12: 0x00000008004204ec libtextstyle.so.0`ostream_write_str(stream=0x0000000800e3a000, string=".\nThis is free software: you are free to change and redistribute it.\nThere is NO WARRANTY, to the extent permitted by law.\n") at ostream.oo.c:35:3
> >     frame #13: 0x0000000000210add poke`pk_puts(str=".\nThis is free software: you are free to change and redistribute it.\nThere is NO WARRANTY, to the extent permitted by law.\n") at pk-term.c:257:3
> > 
> > 
> > Iny my case, there is a NULL pointer dereference in delay_output_ch(), where my_outch is NULL:
> > 
> >     frame #0: 0x00000008009ed2da libncursesw.so.9`delay_output_sp(sp=0x0000000000000000, ms=4) at lib_tputs.c:103:22
> >    100          register int nullcount;
> >    101
> >    102          nullcount = (ms * _nc_baudrate(ospeed)) / (BAUDBYTE * 1000);
> > -> 103          for (_nc_nulls_sent += nullcount; nullcount > 0; nullcount--)
> >    104              my_outch(NCURSES_SP_ARGx PC);
> >    105          if (my_outch == NCURSES_SP_NAME(_nc_outch))
> >    106              NCURSES_SP_NAME(_nc_flush) (NCURSES_SP_ARG);
> > 
> > Application is using term_styled_ostream_create() that does not initialize default_attr.
> > 
> > > On 30 Mar 2021, at 01:31, Thomas Dickey <dickey_at_his.com> wrote:
> > > 
> > > On Mon, Mar 29, 2021 at 12:12:55PM -0700, Henric Jungheim wrote:
> > >> 
> > >> I ran into a bit of an odd problem when building the
> > >> sysutils/grub2-bhyve port on 13.0-RC3 (on x64).  The bison command
> > >> dumps core when the output is going to a console.  Redirecting the
> > >> build output to a file avoids the problem.  I'm not sure if this is
> > >> an ncurses issue, a port issue (and which port?), my box, or
> > >> something else (clang?).
> > > 
> > > It might be a problem with the application's initialization of ncurses.
> > 
> 
> 
> 
> -- 
> Thomas E. Dickey <dickey_at_invisible-island.net>
> https://invisible-island.net
> ftp://ftp.invisible-island.net