From owner-freebsd-current@freebsd.org Wed Mar 31 00:48:06 2021 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D0F475B51F0 for ; Wed, 31 Mar 2021 00:48:06 +0000 (UTC) (envelope-from btv1==724a74bacf2==tom@invisible-island.net) Received: from smtp-1a.his.com (smtp-1a.his.com [216.194.196.25]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4F972t04sxz3qyT for ; Wed, 31 Mar 2021 00:48:05 +0000 (UTC) (envelope-from btv1==724a74bacf2==tom@invisible-island.net) Received: from cuda201.his.com (cuda201.his.com [216.194.196.22]) by smtp-1a.his.com (Postfix) with ESMTPS id F091AAF for ; Tue, 30 Mar 2021 20:48:04 -0400 (EDT) X-ASG-Debug-ID: 1617151684-061c417acf0a6b0001-85yNCL Received: from smtp-nf-202.his.com (smtp-nf-202.his.com [216.194.196.20]) by cuda201.his.com with ESMTP id mqJDW5gTHVbGJpYM; Tue, 30 Mar 2021 20:48:04 -0400 (EDT) X-Barracuda-Envelope-From: tom@invisible-island.net X-Barracuda-RBL-Trusted-Forwarder: 216.194.196.20 Received: from zproxy101.his.com (zproxy101.his.com [18.218.2.49]) by smtp-nf-202.his.com (Postfix) with ESMTPS id 420D760982; Tue, 30 Mar 2021 20:48:04 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by zproxy101.his.com (Postfix) with ESMTP id 0C943178099; Tue, 30 Mar 2021 20:48:04 -0400 (EDT) X-Barracuda-RBL-IP: 18.218.2.49 X-Barracuda-Effective-Source-IP: zproxy101.his.com[18.218.2.49] X-Barracuda-Apparent-Source-IP: 18.218.2.49 Received: from zproxy101.his.com ([127.0.0.1]) by localhost (zproxy101.his.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id lOYIN8EX5OvQ; Tue, 30 Mar 2021 20:48:03 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by zproxy101.his.com (Postfix) with ESMTP id E79201780BA; Tue, 30 Mar 2021 20:48:03 -0400 (EDT) X-Virus-Scanned: amavisd-new at zproxy101.his.com Received: from zproxy101.his.com ([127.0.0.1]) by localhost (zproxy101.his.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ni5xoGllOB2y; Tue, 30 Mar 2021 20:48:03 -0400 (EDT) Received: from prl-debianold-64.jexium-island.net (static-71-246-219-82.washdc.fios.verizon.net [71.246.219.82]) by zproxy101.his.com (Postfix) with ESMTPSA id C7F58178099; Tue, 30 Mar 2021 20:48:03 -0400 (EDT) Received: from tom by prl-debianold-64.jexium-island.net with local (Exim 4.92) (envelope-from ) id 1lRP1f-0000S0-Cn; Tue, 30 Mar 2021 20:48:03 -0400 Date: Tue, 30 Mar 2021 20:48:03 -0400 From: Thomas Dickey To: Juraj Lutter Cc: dickey@his.com, Henric Jungheim , FreeBSD-current@freebsd.org Subject: Re: 13.0-RC3 bison causes tputs SIGSEGV Message-ID: <20210331004803.GA1607@prl-debianold-64.jexium-island.net> X-ASG-Orig-Subj: Re: 13.0-RC3 bison causes tputs SIGSEGV Reply-To: dickey@his.com References: <20210329233138.GA4334@prl-debianold-64.jexium-island.net> <33EE2402-4447-4168-AB5B-D98009CD03AA@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LQksG6bCIzRHxTLp" Content-Disposition: inline In-Reply-To: <33EE2402-4447-4168-AB5B-D98009CD03AA@FreeBSD.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-Barracuda-Connect: smtp-nf-202.his.com[216.194.196.20] X-Barracuda-Start-Time: 1617151684 X-Barracuda-URL: https://spam.his.com:443/cgi-mod/mark.cgi X-Barracuda-BRTS-Status: 1 X-Virus-Scanned: by bsmtpd at his.com X-Barracuda-Scan-Msg-Size: 5302 X-Barracuda-Spam-Score: 0.50 X-Barracuda-Spam-Status: No, SCORE=0.50 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=6.0 tests=BSF_RULE7568M X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.88904 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.50 BSF_RULE7568M Custom Rule 7568M X-Rspamd-Queue-Id: 4F972t04sxz3qyT X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of btv1==724a74bacf2==tom@invisible-island.net designates 216.194.196.25 as permitted sender) smtp.mailfrom=btv1==724a74bacf2==tom@invisible-island.net X-Spamd-Result: default: False [-3.20 / 15.00]; HAS_REPLYTO(0.00)[dickey@his.com]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:216.194.196.0/22]; REPLYTO_ADDR_EQ_FROM(0.00)[]; SIGNED_PGP(-2.00)[]; FORGED_SENDER(0.30)[dickey@his.com,btv1==724a74bacf2==tom@invisible-island.net]; RCVD_IN_DNSWL_LOW(-0.10)[216.194.196.25:from]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[216.194.196.25:from]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FROM_NEQ_ENVFROM(0.00)[dickey@his.com,btv1==724a74bacf2==tom@invisible-island.net]; ASN(0.00)[asn:11604, ipnet:216.194.196.0/24, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_SPAM_SHORT(1.00)[1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[his.com]; SPAMHAUS_ZRD(0.00)[216.194.196.25:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_SEVEN(0.00)[10]; MAILMAN_DEST(0.00)[FreeBSD-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2021 00:48:06 -0000 --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) 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) at lib_tputs.c:116:12 > frame #3: 0x00000008009edb72 libncursesw.so.9`tputs_sp(sp=3D, string=3D"", affcnt=3D1, outc=3D) 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 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 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--