From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail-vi1eur05on2040.outbound.protection.outlook.com ([40.107.21.40] helo=EUR05-VI1-obe.outbound.protection.outlook.com) by metis.ext.pengutronix.de with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kxuQ8-0000Kn-4f for ptxdist@pengutronix.de; Fri, 08 Jan 2021 17:15:27 +0100 References: <20210108084627.GB3422558@pengutronix.de> From: Christian Melki Message-ID: Date: Fri, 8 Jan 2021 17:15:19 +0100 In-Reply-To: <20210108084627.GB3422558@pengutronix.de> Content-Language: en-US MIME-Version: 1.0 Subject: Re: [ptxdist] Bad ncurses configuration for mconf? List-Id: PTXdist Development Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: ptxdist@pengutronix.de, christian.melki@t2data.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: ptxdist-bounces@pengutronix.de Sender: "ptxdist" To: ptxdist@pengutronix.de Hi. I've since reported the error to the maintainer of Ncurses and to the slackware community, but it seems the general understanding of ncurses packaging is low when I ask around. Anyway. Here is an excerpt from parts of the dialog with the maintainer. Might be useful for someone for reference. I've rebuilt with a 20201219 snapshot. It does not fix the issue. Problem remains. But a bit clearer. Investigated the win->line allocation. After initscr the value seems ok. (gdb) print stdscr->_line[0] $14 = {text = 0xce2a10, firstchar = 0, lastchar = 301, oldindex = 0} (gdb) print stdscr->_line[1] $15 = {text = 0xce2ed0, firstchar = 0, lastchar = 301, oldindex = 0} (gdb) print stdscr->_line[2] $16 = {text = 0xce3390, firstchar = 0, lastchar = 301, oldindex = 0} (gdb) print stdscr->_line[3] $17 = {text = 0xce3850, firstchar = 0, lastchar = 301, oldindex = 0} Breakpoint 1, main (ac=2, av=0x7ffffffefb28) at mconf.c:1000 1000 signal(SIGINT, sig_handler); (gdb) c Continuing. Breakpoint 3, init_dialog (backtitle=backtitle@entry=0x0) at lxdialog/util.c:319 319 initscr(); /* Init curses */ (gdb) c Continuing. Breakpoint 4, initscr () at ../ncurses/./base/lib_initscr.c:56 56 START_TRACE(); (gdb) c Continuing. Hardware watchpoint 5: stdscr->_line[1]->text Old value = New value = (chtype *) 0xce2ed0 _nc_setupscreen_sp (spp=0x7ffffffef938, slines=49, scolumns=302, output=0x7ffff7f236a0 <_IO_2_1_stdout_>, filtered=0, slk_format=0) at ../ncurses/./base/lib_set_term.c:744 744 sp->_prescreen = FALSE; (gdb) c Continuing. Hardware watchpoint 5: stdscr->_line[1]->text Old value = (chtype *) 0xce2ed0 New value = (chtype *) 0x100ce2ed0 0x0000000000415c3f in attr_clear (win=0xce2690, height=49, width=width@entry=302, attr=2097408) at lxdialog/util.c:247 247 for (i = 0; i < height; i++) { (gdb) n 248 wmove(win, i, 0); (gdb) n 249 for (j = 0; j < width; j++) (gdb) n 250 waddch(win, ' '); (gdb) print i $28 = 0 (gdb) print j $29 = 0 And at the segfault... (gdb) print win->_line[0] $9 = {text = 0xce2a10, firstchar = 0, lastchar = 301, oldindex = 0} (gdb) print win->_line[1] $10 = {text = 0x100ce2ed0, firstchar = 0, lastchar = 301, oldindex = 0} (gdb) print win->_line[2] $11 = {text = 0xce3390, firstchar = 0, lastchar = 301, oldindex = 0} (gdb) print win->_line[3] $12 = {text = 0xce3850, firstchar = 0, lastchar = 301, oldindex = 0} Seems the line text pointer is botched by something. So in summary a pointer gets corrupted with the same operand value with what seems to be a bitwise "or" macro operation. On 1/8/21 9:46 AM, Michael Olbrich wrote: > On Fri, Dec 25, 2020 at 09:08:14PM +0100, Christian Melki wrote: >> Ptxdist seems to assume things about the ncurses local build that doesn't >> always turn up to be usable. >> >> I use a ncurses-6.2 build in Slackware. Pretty normal build. >> >> mconf headers point to the ncurses library, not ncursesw. >> >> mconf gets built with: >> -O2 -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 >> and is linked with: >> linux-vdso.so.1 (0x00007ffcd5f30000) >> libncurses.so.6 => /lib64/libncurses.so.6 (0x00007f6914c68000) >> libtinfo.so.6 => /lib64/libtinfo.so.6 (0x00007f6914c37000) >> libc.so.6 => /lib64/libc.so.6 (0x00007f6914a52000) >> libdl.so.2 => /lib64/libdl.so.2 (0x00007f6914a4d000) >> /lib64/ld-linux-x86-64.so.2 (0x00007f6914cbd000) >> >> And mconf segfaults with: >> Program received signal SIGSEGV, Segmentation fault. >> 0x00007ffff7f84b9a in waddch () from /lib64/libncurses.so.6 >> >> (gdb) bt >> #0 0x00007ffff7f84b9a in waddch () from /lib64/libncurses.so.6 >> #1 0x0000000000415c78 in attr_clear (win=0xcdf820, height=49, width=299, >> attr=) at lxdialog/util.c:250 >> #2 0x0000000000415cfc in dialog_clear () at lxdialog/util.c:262 >> #3 0x0000000000416274 in init_dialog (backtitle=backtitle@entry=0x0) at >> lxdialog/util.c:336 >> #4 0x000000000040272c in main (ac=2, av=0x7ffffffefd78) at mconf.c:1017 >> >> ... second loop pass. Height = 0 passes the width loop. Height = 1, Width = >> 0 segfaults. >> >> (gdb) print j >> $8 = 298 >> (gdb) n >> 250 waddch(win, ' '); >> (gdb) n >> 249 for (j = 0; j < width; j++) >> (gdb) n >> 247 for (i = 0; i < height; i++) { >> (gdb) n >> 248 wmove(win, i, 0); >> (gdb) print i >> $9 = 1 >> (gdb) n >> 249 for (j = 0; j < width; j++) >> (gdb) n >> 250 waddch(win, ' '); >> (gdb) n >> Program received signal SIGSEGV, Segmentation fault. >> >> I am not sure what to blame here or if I understand things. >> Or if it's resonable that ncurses should explode like this. >> >> Seems pkg-config cflags answers: >> pkg-config --cflags ncurses -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 >> >> But if I understand things >= 600 = wide char header? >> the pkg-config answers the same for ncursesw. > > I see the same pkg-config results here on Debian. > I have no idea how this is supposed to work. > >> So the program will compile and link just fine. >> If I use xterm and rxvt as $TERM the mconf program crashes, but is fine with >> vt100. >> >> Is this related to ext-colors support somehow? >> If I force the program to link with ncursesw, then all is fine. > > Hmmm, what happens if you add -DNCURSES_WIDECHAR=0 to the cflags and link > with ncurses? Does it work correctly now? I think this is controlled through the headers with the XOPEN_SOURCE level unless specified otherwise (ifndef)? In curses.h: #ifndef NCURSES_WIDECHAR #if defined(_XOPEN_SOURCE_EXTENDED) || (defined(_XOPEN_SOURCE) && (_XOPEN_SOURCE - 0 >= 500)) #define NCURSES_WIDECHAR 1 #else #define NCURSES_WIDECHAR 0 #endif #endif /* NCURSES_WIDECHAR */ But yes. Your suggestion works. I have never needed widechar for ptxdist. Anyway. This is what you meant? Could be useful for forcibly disable wide char extensions if you're linking with ncurses only. --- configure.ac~ 2020-12-16 16:42:25.000000000 +0100 +++ configure.ac 2021-01-08 16:50:08.440868020 +0100 @@ -68,7 +68,7 @@ [AC_MSG_ERROR([ncurses headers not found])]) AC_SUBST(CURSES_LOC) -CPPFLAGS="${NCURSES_CFLAGS}" +CPPFLAGS="${NCURSES_CFLAGS} -DNCURSES_WIDECHAR=0" AC_ARG_WITH(ncurses, AS_HELP_STRING([--with-ncurses],[Include path to the ncurses headers]), [ if test "x$withval" != "xyes"; then >> My best guess is that the terminal is ext-color, program gets built with >> wchar-support but linked with ncurses. >> This probably shouldn't explode in ncurses, but I think it's also a >> misconfiguration build. >> >> I would suggest that ptxdist uses ncursesw + headers if found and ncurses >> without wchar if not found. >> >> Kernel seems to prefer something similar? >> https://elixir.bootlin.com/linux/v5.10.2/source/scripts/kconfig/mconf-cfg.sh > > The whole ncurses handling in configure.ac should probably cleaned up and > simplified. > > Michael > _______________________________________________ ptxdist mailing list ptxdist@pengutronix.de To unsubscribe, send a mail with subject "unsubscribe" to ptxdist-request@pengutronix.de