Date: Sat, 3 Apr 2021 14:36:29 -0400 From: Thomas Dickey <dickey@his.com> To: Juraj Lutter <otis@FreeBSD.org>, Henric Jungheim <software@henric.org>, FreeBSD-current@freebsd.org Subject: Re: 13.0-RC3 bison causes tputs SIGSEGV Message-ID: <20210403183629.GA27381@prl-debianold-64.jexium-island.net> In-Reply-To: <20210331235409.GA8773@prl-debianold-64.jexium-island.net> References: <YGImt%2BhzWnQTUjz/@mail.henric.info> <20210329233138.GA4334@prl-debianold-64.jexium-island.net> <33EE2402-4447-4168-AB5B-D98009CD03AA@FreeBSD.org> <20210331004803.GA1607@prl-debianold-64.jexium-island.net> <YGR%2B1yOzagxgvpqk@mail.henric.info> <7E5FFF68-3FDC-42C4-A1C9-4B2F483FABC5@FreeBSD.org> <20210331224955.GA8387@prl-debianold-64.jexium-island.net> <20210331235409.GA8773@prl-debianold-64.jexium-island.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--IJpNTDwzlM2Ie8A6
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
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:
> > >=20
> > > > On 31 Mar 2021, at 15:53, Henric Jungheim <software@henric.org> wro=
te:
> > > >=20
> > > >>=20
> > > >> Knowing that would help me see whether the problem is faulty initi=
alization
> > > >> from libtextstyle (i.e., the SCREEN pointer is null, making the pa=
th via
> > > >> the static structure), or some ifdef-combination in ncurses that I=
've
> > > >> neglected (i.e., a flaw in the pointer juggling).
> > >=20
> > > I=E2=80=99ve observed that the application in question calls:
> > >=20
> > > /* Create the output styled stream. */
> > > pk_ostream =3D
> > > (color_mode =3D=3D color_html
> > > ? html_styled_ostream_create (file_ostream_create (stdout),
> > > style_file_name)
> > > : styled_ostream_create (STDOUT_FILENO, "(stdout)",
> > > TTYCTL_AUTO, style_file_name));
> > >=20
> > > Does it make any difference?
> >=20
> > 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).
>=20
> ...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".
=20
> 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).
>=20
> 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 interfa=
ce.
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=3D"4f0fdc740005b=
ebaf92e5a2e00000000", affcnt=3D1, outc=3D(libtextstyle.so.0`out_char at ter=
m-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 librar=
y.
In my own testing, these two tputs calls don't correspond to anything in the
terminal description (same problem):
tputs("\e]8;id=3D", 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) =3D (async_safe ? out_char_unchecked : out_char);
assert (stream->supports_hyperlink);
if (new_hyperlink !=3D NULL)
{
assert (new_hyperlink->real_id !=3D NULL);
tputs ("\033]8;id=3D", 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.
--=20
Thomas E. Dickey <dickey@invisible-island.net>
https://invisible-island.net
ftp://ftp.invisible-island.net
--IJpNTDwzlM2Ie8A6
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iF0EABECAB0WIQTFIEjAwHSP7iJ9R6JwI1Pg9+SO2wUCYGi1pwAKCRBwI1Pg9+SO
21qPAJwJPOikC72XIKn32tNxjbWpPLWzCgCgm5Hx+t5V1JsbF1yTWfWu5nxAyZw=
=6o5K
-----END PGP SIGNATURE-----
--IJpNTDwzlM2Ie8A6--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20210403183629.GA27381>