Date: Tue, 30 Mar 2021 20:48:03 -0400 From: Thomas Dickey <dickey@his.com> To: Juraj Lutter <otis@FreeBSD.org> Cc: dickey@his.com, Henric Jungheim <software@henric.org>, FreeBSD-current@freebsd.org Subject: Re: 13.0-RC3 bison causes tputs SIGSEGV Message-ID: <20210331004803.GA1607@prl-debianold-64.jexium-island.net> In-Reply-To: <33EE2402-4447-4168-AB5B-D98009CD03AA@FreeBSD.org> References: <YGImt%2BhzWnQTUjz/@mail.henric.info> <20210329233138.GA4334@prl-debianold-64.jexium-island.net> <33EE2402-4447-4168-AB5B-D98009CD03AA@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--LQksG6bCIzRHxTLp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 30, 2021 at 08:37:22AM +0200, Juraj Lutter wrote: > Hi, >=20 > very similar behavior is observed in editors/poke, on recent 13.0-STABLE = (stable/13-85ad493677a2): >=20 > (lldb) bt > * thread #1, name =3D 'poke', stop reason =3D signal SIGSEGV: invalid add= ress (fault address: 0x0) > * frame #0: 0x0000000000000000 > frame #1: 0x00000008009ed30a libncursesw.so.9`delay_output_sp(sp=3D0x= 0000000000000000, ms=3D<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] dela= y_output(ms=3D<unavailable>) at lib_tputs.c:116:12 > frame #3: 0x00000008009edb72 libncursesw.so.9`tputs_sp(sp=3D<unavaila= ble>, string=3D"", affcnt=3D1, outc=3D<unavailable>) at lib_tputs.c:422 > frame #4: 0x00000008009edcfb libncursesw.so.9`tputs(string=3D"4f0fdc7= 40005bebaf92e5a2e00000000", affcnt=3D1, outc=3D(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,=20 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 =66rom 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(s= tream=3D0x0000000800e3d000, new_hyperlink=3D0x00000008018bd600, async_safe= =3Dfalse) at term-ostream.oo.c:1586:7 > frame #6: 0x000000080042579c libtextstyle.so.0`out_attr_change(stream= =3D0x0000000800e3d000, new_attr=3Dattributes_t @ 0x00007fffffffe608) at ter= m-ostream.oo.c:1737:11 > frame #7: 0x0000000800424f3b libtextstyle.so.0`output_buffer(stream= =3D0x0000000800e3d000, goal_attr=3Dattributes_t @ 0x00007fffffffe690) at te= rm-ostream.oo.c:1906:11 > frame #8: 0x00000008004223b2 libtextstyle.so.0`term_ostream__write_me= m(stream=3D0x0000000800e3d000, data=3D0x0000000000207a94, len=3D123) at ter= m-ostream.oo.c:2037:11 > frame #9: 0x0000000800422ed5 libtextstyle.so.0`term_ostream_write_mem= (first_arg=3D0x0000000800e3d000, data=3D0x0000000000207a94, len=3D123) at t= erm-ostream.c:2721:3 > frame #10: 0x0000000800427e3f libtextstyle.so.0`term_styled_ostream__= write_mem(stream=3D0x0000000800e3a000, data=3D0x0000000000207a94, len=3D123= ) at term-styled-ostream.oo.c:95:3 > frame #11: 0x0000000800420535 libtextstyle.so.0`ostream_write_mem(fir= st_arg=3D0x0000000800e3a000, data=3D0x0000000000207a94, len=3D123) at ostre= am.c:138:3 > frame #12: 0x00000008004204ec libtextstyle.so.0`ostream_write_str(str= eam=3D0x0000000800e3a000, string=3D".\nThis is free software: you are free = to change and redistribute it.\nThere is NO WARRANTY, to the extent permitt= ed by law.\n") at ostream.oo.c:35:3 > frame #13: 0x0000000000210add poke`pk_puts(str=3D".\nThis is free sof= tware: you are free to change and redistribute it.\nThere is NO WARRANTY, t= o the extent permitted by law.\n") at pk-term.c:257:3 >=20 >=20 > Iny my case, there is a NULL pointer dereference in delay_output_ch(), wh= ere my_outch is NULL: >=20 > frame #0: 0x00000008009ed2da libncursesw.so.9`delay_output_sp(sp=3D0x= 0000000000000000, ms=3D4) at lib_tputs.c:103:22 > 100 register int nullcount; > 101 > 102 nullcount =3D (ms * _nc_baudrate(ospeed)) / (BAUDBYTE * 1= 000); > -> 103 for (_nc_nulls_sent +=3D nullcount; nullcount > 0; nullco= unt--) > 104 my_outch(NCURSES_SP_ARGx PC); > 105 if (my_outch =3D=3D NCURSES_SP_NAME(_nc_outch)) > 106 NCURSES_SP_NAME(_nc_flush) (NCURSES_SP_ARG); >=20 > Application is using term_styled_ostream_create() that does not initializ= e default_attr. >=20 > > On 30 Mar 2021, at 01:31, Thomas Dickey <dickey@his.com> wrote: > >=20 > > On Mon, Mar 29, 2021 at 12:12:55PM -0700, Henric Jungheim wrote: > >>=20 > >> 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?). > >=20 > > It might be a problem with the application's initialization of ncurses. >=20 --=20 Thomas E. Dickey <dickey@invisible-island.net> https://invisible-island.net ftp://ftp.invisible-island.net --LQksG6bCIzRHxTLp Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABECAB0WIQTFIEjAwHSP7iJ9R6JwI1Pg9+SO2wUCYGPGvwAKCRBwI1Pg9+SO 2yLlAJ9KVkE8X3rdjL70gs0WdnBjdq/D+wCgvMlvSrh2GC/W5w5U9ygHjtiMiBA= =hHvO -----END PGP SIGNATURE----- --LQksG6bCIzRHxTLp--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20210331004803.GA1607>