Re: 13.0-RC3 bison causes tputs SIGSEGV

On Wed, Mar 31, 2021 at 07:54:09PM -0400, Thomas Dickey wrote:
> On Wed, Mar 31, 2021 at 06:49:55PM -0400, Thomas Dickey wrote:
> > On Wed, Mar 31, 2021 at 09:40:49PM +0200, Juraj Lutter wrote:
> > > 
> > > > On 31 Mar 2021, at 15:53, Henric Jungheim <software_at_henric.org> wrote:
> > > > 
> > > >> 
> > > >> 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).
> > > 
> > > I’ve observed that the application in question calls:
> > > 
> > >   /* Create the output styled stream.  */
> > >   pk_ostream =
> > >     (color_mode == color_html
> > >      ? html_styled_ostream_create (file_ostream_create (stdout),
> > >                                    style_file_name)
> > >      : styled_ostream_create (STDOUT_FILENO, "(stdout)",
> > >                               TTYCTL_AUTO, style_file_name));
> > > 
> > > Does it make any difference?
> > 
> > I don't know yet.  I've been setting up a build for bison+libtextstyle
> > so that I can study it firsthand (and use valgrind, etc., to look for
> > problems).
> 
> ...valgrind on Debian/testing (iirc, valgrind doesn't work with BSDs).

I did try valgrind from ports, but "valgrind" is old/blocked, and
"valgrind-devel" did not run because it doesn't support "rfork".
 
> However, aside from the cgetent stuff, the terminfo part of my test-setup
> matches what's in FreeBSD's build for ncurses.  valgrind finds nothing
> amiss with the tests that I've done to exercise the libtextstyle code.
> (address-sanitizer may).
> 
> By the way, ktruss could show what files are opened in your configuration,
> and a log from that would tell me if it's reading via the termcap interface.

Henric Jungheim followed up with details that showed me it was using the
termcap database.

The core dump is due to my not making the tputs_sp function call
delay_output_sp for the BSD padding special case (it's calling delay_output),
with the result that the SCREEN pointer sp gets passed in as a null.

That's a simple fix, which will be in today's update for ncurses.

There're additional bugs however.  The libtextstyle library is basically
passing garbage down to tputs in this case.  This line from the stack
trace

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

is passing a string "4f0fdc740005bebaf92e5a2e00000000", which (because
it happens to begin with a digit) runs into that special case.  The
string itself is garbage -- it's not a result from tparm (see attached
ncurses trace), but appears to have been made up by the libtextstyle library.

In my own testing, these two tputs calls don't correspond to anything in the
terminal description (same problem):

tputs("\e]8;id=", 1, 0x0800838860) called
tputs("933ed1a10005bf11f4fd265c00000000", 1, 0x0800838860) called
called {delay_output(0x7fffffff9000,933)

That comes from this chunk in libtextstyle:

/* Output escape seqeuences to switch the hyperlink to NEW_HYPERLINK.  */
static _GL_ASYNC_SAFE void
out_hyperlink_change (term_ostream_t stream, hyperlink_t *new_hyperlink,
                      bool async_safe)
{
  int (*out_ch) (int) = (async_safe ? out_char_unchecked : out_char);
  assert (stream->supports_hyperlink);
  if (new_hyperlink != NULL)
    {
      assert (new_hyperlink->real_id != NULL);
      tputs ("\033]8;id=",           1, out_ch);
      tputs (new_hyperlink->real_id, 1, out_ch);
      tputs (";",                    1, out_ch);
      tputs (new_hyperlink->ref,     1, out_ch);
      tputs ("\033\\",               1, out_ch);
    }
  else
    tputs ("\033]8;;\033\\", 1, out_ch);
}

If it happens to work for some people, that's purely accidental.

-- 
Thomas E. Dickey <dickey_at_invisible-island.net>
https://invisible-island.net
ftp://ftp.invisible-island.net