bug-ncurses
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Segment Fault of newterm in ncurses-6.1_p20190609


From: Thomas Dickey
Subject: Re: Segment Fault of newterm in ncurses-6.1_p20190609
Date: Mon, 19 Aug 2019 20:39:13 -0400
User-agent: NeoMutt/20170113 (1.7.2)

On Mon, Aug 19, 2019 at 10:54:33PM +0800, Han Han wrote:
> On Sun, Aug 18, 2019 at 1:21 AM Thomas Dickey <address@hidden> wrote:
> 
> > On Sat, Aug 17, 2019 at 10:37:32AM -0400, Thomas Dickey wrote:
> > > On Sat, Aug 17, 2019 at 03:26:55PM +0800, Han Han wrote:
> > > > Versions:
> > > > ncurses-6.1_p20190609
> > > > gpm-1.20.7-r2
> > > > gdb-8.3
> > > > pinfo-0.6.13
> > >
> > > for context, Rawhide has these:
> > >
> > > ncurses-6.1-10.20180923.fc30.x86_64
> > > gpm-1.20.7-18.fc30.x86_64
> > > gdb-8.3-6.fc30.x86_64
> > > pinfo-0.6.10-20.fc29.x86_64
> > >
> > > > Steps:
> > > > It could be trigger by gdb or pinfo
> > > > I. for gdb:
> > > > # gdb -tui ls
> > > > [1]    3348 segmentation fault (core dumped)  gdb -tui ls
> > > >
> > > > II. for pinfo:
> > > > # pinfo close
> > > > Caught signal 11, bye!
> > > > pinfo: crash with: Success
> > >
> > > hmm - pinfo's easier to test (I'll focus on this).
> > >
> > > I don't see a clue regarding the terminal description used (i.e., $TERM).
> > >
> > > If I'd gotten a crash, the next step would be to run the application with
> > > valgrind to see if it could tell me anything.
> >
> > I need more information to be able to reproduce the problem.
> > The configuration described is apparently not a Red Hat package build,
> > since it is not listed here:
> >
> Hello, my system is not Fedora or Redhat. It is gentoo. And the ncurses is
> build by
> gcc-9.2.0. The configure of ncurses is:
> ./configure --prefix=/usr --build=x86_64-pc-linux-gnu
> --host=x86_64-pc-linux-gnu --mandir=/usr/share/man
> --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc
> --localstatedir=/var/lib --libdir=/usr/lib64
> --with-terminfo-dirs=/etc/terminfo:/usr/share/terminfo --enable-pc-files
> --with-pkg-config-libdir=/usr/lib64/pkgconfig --with-shared
> --without-hashed-db --without-ada --with-cxx --with-cxx-binding
> --with-cxx-shared --without-debug --without-profile --with-gpm=libgpm.so.1
> --disable-term-driver --disable-termcap --enable-symlinks --with-rcs-ids
> --with-manpage-format=normal --enable-const --enable-colorfgbg
> --enable-hard-tabs --enable-echo --enable-warnings --without-assertions
> --enable-leaks --without-expanded --with-macros --with-progs
> --without-tests --without-trace --with-termlib --disable-stripping
> --disable-widec --without-pthread --without-reentrant --enable-overwrite
> 
> My terminal:
> # echo $TERM
> xterm-256color
> 
> 
> > https://apps.fedoraproject.org/packages/ncurses/builds/
> >
> > If it had been, and if the problem was not resolved in the two months
> > since the cited patch, I should be able to reproduce it by the most
> > recent Fedora build.  Just to be sure, I rebuilt (in my rawhide machine)
> > this package:
> >
> > https://koji.fedoraproject.org/koji/buildinfo?buildID=1348376
> > (ncurses-6.1-12.20190803.fc31).
> >
> > and did the same for the current pinfo.  While valgrind shows me
> > some problems from pinfo, none of those are related to ncurses
> > (see attached log).
> >
> For the report of valgrind, see the attachment
> 
> >
> > fwiw, that's with TERM=xterm-256color, taking care to use the
> > corresponding ncurses-base and ncurses-term packages.
> >
> > --
> > Thomas E. Dickey <address@hidden>
> > https://invisible-island.net
> > ftp://ftp.invisible-island.net
> >
> 
> 
> -- 
> Best regards,
> -----------------------------------
> Han Han
> Quality Engineer
> Redhat.
> 
> Email: address@hidden
> Phone: +861065339333

> ==22718== Memcheck, a memory error detector
> ==22718== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
> ==22718== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
> ==22718== Command: pinfo close
> ==22718== Parent PID: 587
> ==22718== 
> ==22718== Invalid read of size 8
> ==22718==    at 0x48F1340: termattrs_sp (lib_vidattr.c:381)
> ==22718==    by 0x48EE6BE: _nc_setupscreen_sp (lib_set_term.c:507)
> ==22718==    by 0x48E9E4D: newterm_sp (lib_newterm.c:222)
> ==22718==    by 0x48EA2D7: newterm (lib_newterm.c:355)
> ==22718==    by 0x119243: init_curses (utils.c:410)
> ==22718==    by 0x1155F4: handlemanual (manual.c:294)
> ==22718==    by 0x10BF52: main (pinfo.c:312)
> ==22718==  Address 0x4e6ff60 is 32 bytes before a block of size 32 in arena 
> "client"
> ==22718== 
> ==22718== Invalid read of size 8
> ==22718==    at 0x48F1349: termattrs_sp (lib_vidattr.c:382)
> ==22718==    by 0x48EE6BE: _nc_setupscreen_sp (lib_set_term.c:507)
> ==22718==    by 0x48E9E4D: newterm_sp (lib_newterm.c:222)
> ==22718==    by 0x48EA2D7: newterm (lib_newterm.c:355)
> ==22718==    by 0x119243: init_curses (utils.c:410)
> ==22718==    by 0x1155F4: handlemanual (manual.c:294)
> ==22718==    by 0x10BF52: main (pinfo.c:312)
> ==22718==  Address 0x128 is not stack'd, malloc'd or (recently) free'd

Lines 381-382 in lib_vidattr.c shown here:
        if (enter_alt_charset_mode)
            attrs |= A_ALTCHARSET;

attrs is a local variable (on the stack), A_ALTCHARSET is a constant.
        #define NCURSES_ATTR_SHIFT       8
        #define NCURSES_BITS(mask,shift) (NCURSES_CAST(chtype,(mask)) << 
((shift) + NCURSES_ATTR_SHIFT))
        #define A_ALTCHARSET    NCURSES_BITS(1U,14)

enter_alt_charset_mode is part of a struct pointed to by cur_term
        #define enter_alt_charset_mode         CUR Strings[25]

Your valgrind report lists two problems, but only cur_term could be
a problem.  It's initialized earlier in _nc_setupscreen_sp (a side
effect of _nc_set_screen).

Perhaps someone patched that source, or the 20190609 is incorrect.
Or (since you're using ncurses+tinfo), perhaps the wrong version
of tinfo is being loaded.

When I run valgrind, it shows the libraries which are loaded,
since I use the "-v" option:

OPTS="-v \
        --num-callers=10 \
        --error-limit=no \
        --show-reachable=yes \
        --leak-resolution=high \
        --track-origins=yes \
        --leak-check=yes \
        --show-reachable=yes"

If you do that, you might see a problem.

> ==22718== 
> ==22718== 
> ==22718== HEAP SUMMARY:
> ==22718==     in use at exit: 608,266 bytes in 568 blocks
> ==22718==   total heap usage: 2,157 allocs, 1,589 frees, 3,083,059 bytes 
> allocated
> ==22718== 
> ==22718== LEAK SUMMARY:
> ==22718==    definitely lost: 0 bytes in 0 blocks
> ==22718==    indirectly lost: 0 bytes in 0 blocks
> ==22718==      possibly lost: 0 bytes in 0 blocks
> ==22718==    still reachable: 608,266 bytes in 568 blocks
> ==22718==         suppressed: 0 bytes in 0 blocks
> ==22718== Rerun with --leak-check=full to see details of leaked memory
> ==22718== 
> ==22718== For lists of detected and suppressed errors, rerun with: -s
> ==22718== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
> ==22718== could not unlink /tmp/vgdb-pipe-from-vgdb-to-22718-by-root-on-???
> ==22718== could not unlink /tmp/vgdb-pipe-to-vgdb-from-22718-by-root-on-???
> ==22718== could not unlink /tmp/vgdb-pipe-shared-mem-vgdb-22718-by-root-on-???


-- 
Thomas E. Dickey <address@hidden>
https://invisible-island.net
ftp://ftp.invisible-island.net

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]