From owner-freebsd-current@freebsd.org Wed Mar 31 13:53:35 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 531EF578FCA for ; Wed, 31 Mar 2021 13:53:35 +0000 (UTC) (envelope-from henric@henric.org) Received: from mail.henric.info (mail.henric.info [199.48.129.194]) (using TLSv1.3 with cipher TLS_CHACHA20_POLY1305_SHA256 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4F9STC057jz3P3Q; Wed, 31 Mar 2021 13:53:34 +0000 (UTC) (envelope-from henric@henric.org) Received: by mail.henric.info (Postfix, from userid 1001) id 94912233816; Wed, 31 Mar 2021 06:53:27 -0700 (MST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=henric.org; s=20180330; t=1617198807; bh=g46w2Rb/YYHapbzOhG6BHFb2B/mhjhOVOQEzNHw7hTo=; h=Date:From:To:Subject:Message-ID:MIME-Version:Content-Type: In-Reply-To; b=AO1Lrp/L1nH0fLSM7D9pCE8/wRBwAx0SxRAX7EBd8bbzQGqGsBw/wleV1jI2cx7sL v/I8ow/eeCLza1xhnYY7z3C58MabuSWC56rYv8BZOTkbcZ+ra94ksVTAqbXag+SaBa c3swrsJwuJLm7Lk8lUQeOBwTomWTc+so2qx3IATGHgZMf5HHNndV6LQNVXxOgjla+H +HEhULx5u50GAXV23YPy7gD70urH+42JKNPmAyxvO4gSuFbhVEazlNj4MWghyBiBvJ MrKqpo6gY5JzwTdo9S0g8xCN1cpLJ/6kvmsBi2REmrihZqp/VTTglEoUXDSKRDxFSG xUAolMBfJSZ0g== Date: Wed, 31 Mar 2021 06:53:27 -0700 From: Henric Jungheim To: Thomas Dickey Cc: Juraj Lutter , FreeBSD-current@freebsd.org Subject: Re: 13.0-RC3 bison causes tputs SIGSEGV Message-ID: References: <20210329233138.GA4334@prl-debianold-64.jexium-island.net> <33EE2402-4447-4168-AB5B-D98009CD03AA@FreeBSD.org> <20210331004803.GA1607@prl-debianold-64.jexium-island.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210331004803.GA1607@prl-debianold-64.jexium-island.net> X-Rspamd-Queue-Id: 4F9STC057jz3P3Q X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Mailman-Approved-At: Wed, 31 Mar 2021 16:57:09 +0000 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 13:53:35 -0000 On Tue, Mar 30, 2021 at 08:48:03PM -0400, Thomas Dickey wrote: > 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=) 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=) at lib_tputs.c:116:12 > > frame #3: 0x00000008009edb72 libncursesw.so.9`tputs_sp(sp=, string="", affcnt=1, outc=) 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). In the example in my original email, $TERM was "xterm-256color" (connected through "Windows Terminal" running MS' ssh on Win10). > > 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 @ 0x00007fffffffe608) at term-ostream.oo.c:1737:11 > > frame #7: 0x0000000800424f3b libtextstyle.so.0`output_buffer(stream=0x0000000800e3d000, goal_attr=attributes_t @ 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 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 > https://invisible-island.net > ftp://ftp.invisible-island.net