Re: 13.0-RC3 bison causes tputs SIGSEGV

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).

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