Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 669096 - sys-devel/gdb-8.2: crashes on 'layout asm'
Summary: sys-devel/gdb-8.2: crashes on 'layout asm'
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Toolchain Maintainers
URL:
Whiteboard:
Keywords:
: 649704 (view as bug list)
Depends on:
Blocks:
 
Reported: 2018-10-20 21:14 UTC by Michał Górny
Modified: 2019-04-03 06:51 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
gdb-8.2-tinfow.patch (gdb-8.2-tinfow.patch,900 bytes, patch)
2018-10-21 11:19 UTC, Sergei Trofimovich
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2018-10-20 21:14:25 UTC
$ gdb
GNU gdb (Gentoo 8.2 p1) 8.2
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://bugs.gentoo.org/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb) layout asm
Segmentation fault (core dumped)


A quick 'bt' gives:
#0  0x00007ffff751f879 in termattrs_sp () from /lib64/libncursesw.so.6
#1  0x00007ffff751cc10 in _nc_setupscreen_sp () from /lib64/libncursesw.so.6
#2  0x00007ffff751828d in newterm_sp () from /lib64/libncursesw.so.6
#3  0x00007ffff7518747 in newterm () from /lib64/libncursesw.so.6
#4  0x0000555555679a5e in ?? ()
#5  0x0000555555681abd in ?? ()


Please let me know if you can reproduce it, or if I need to debug it further.
Comment 1 Sergei Trofimovich gentoo-dev 2018-10-20 21:58:39 UTC
Works here (likely by accident). I guess it's due to both
   /lib64/libncursesw.so.6
and
   /lib64/libncurses.so.6

being linked in into final binary:
  $ lddtree /usr/bin/gdb
  /usr/bin/gdb (interpreter => /lib64/ld-linux-x86-64.so.2)
    libreadline.so.7 => /lib64/libreadline.so.7
        libncurses.so.6 => /lib64/libncurses.so.6
    libncursesw.so.6 => /lib64/libncursesw.so.6
    ...

AFAIU both provide roughly the same set of symbols and thus are not supposed to be linked together.
Comment 2 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2018-10-20 22:10:34 UTC
Yeah, the following seems to work:

$ LD_PRELOAD=libncurses.so.6 gdb

...but why does your readline link to ncurses?
Comment 3 Sergei Trofimovich gentoo-dev 2018-10-21 10:08:54 UTC
CC: base-system@

readline unconditionally pulls in libncurses.so from ebuild:
    https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-libs/readline/readline-7.0_p5.ebuild#n71

readline itself would be fine to use any of 'termcap', 'tinfo', 'ncurses', 'libc'. Whatever provides 'tgetent':

  readline-7.0/configure.ac:
    BASH_CHECK_LIB_TERMCAP -> aclocal.m4
      readline-7.0/aclocal.m4:

  AC_DEFUN([BASH_CHECK_LIB_TERMCAP],
  ...
  [AC_CHECK_FUNC(tgetent, bash_cv_termcap_lib=libc,
    [AC_CHECK_LIB(termcap, tgetent, bash_cv_termcap_lib=libtermcap,
      [AC_CHECK_LIB(tinfo, tgetent, bash_cv_termcap_lib=libtinfo,
        [AC_CHECK_LIB(curses, tgetent, bash_cv_termcap_lib=libcurses,
            [AC_CHECK_LIB(ncurses, tgetent, bash_cv_termcap_lib=libncurses,
                bash_cv_termcap_lib=gnutermcap)])])])])])
  ...
  if test $bash_cv_termcap_lib = gnutermcap && test -z "$prefer_curses"; then
  LDFLAGS="$LDFLAGS -L./lib/termcap"
  TERMCAP_LIB="./lib/termcap/libtermcap.a"
  TERMCAP_DEP="./lib/termcap/libtermcap.a"
  elif test $bash_cv_termcap_lib = libtermcap && test -z "$prefer_curses"; then
  TERMCAP_LIB=-ltermcap
  TERMCAP_DEP=
  elif test $bash_cv_termcap_lib = libtinfo; then
  TERMCAP_LIB=-ltinfo
  TERMCAP_DEP=
  elif test $bash_cv_termcap_lib = libncurses; then
  TERMCAP_LIB=-lncurses
  TERMCAP_DEP=
  elif test $bash_cv_termcap_lib = libc; then
  TERMCAP_LIB=
  TERMCAP_DEP=
  else
  TERMCAP_LIB=-lcurses
  TERMCAP_DEP=
  fi
  ])

I think we need to add ncursesw here.

This gives us a few workarounds:
- force readline into ncursesw when available on ebuild side (would also need passing `pkg-config --cflags ncursesw` as well)
- force readline into -ltinfo depend (via sys-libs/ncurses[tinfo]) and avoid ncurses altogether.

I'd expect multiple readline users to already be affected.

$ lddtree /usr/lib64/python2.7/lib-dynload/readline.so
/usr/lib64/python2.7/lib-dynload/readline.so (interpreter => None)
    libreadline.so.7 => /lib64/libreadline.so.7
        libncurses.so.6 => /lib64/libncurses.so.6
...
    libncursesw.so.6 => /lib64/libncursesw.so.6
...
Comment 4 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2018-10-21 10:48:29 UTC
Oh, so it's tinfo that makes readline not link to ncurses. Which is why it crashes for me.
Comment 5 Sergei Trofimovich gentoo-dev 2018-10-21 10:52:25 UTC
yeah.

> - force readline into -ltinfo depend (via sys-libs/ncurses[tinfo]) and avoid ncurses altogether.

Actually, that does not work either. TIL there are both -ltinfo and -ltinfow.

Finally reproduced SIGSEGV as:

  # USE="tinfo" emerge -v1 ncurses readline sys-devel/gdb
  # lddtree /usr/bin/gdb
   /usr/bin/gdb (interpreter => /lib64/ld-linux-x86-64.so.2)
    libreadline.so.7 => /lib64/libreadline.so.7
    libtinfo.so.6 => /lib64/libtinfo.so.6
    libncursesw.so.6 => /lib64/libncursesw.so.6
        libtinfow.so.6 => /lib64/libtinfow.so.6

This is also likely a gdb bug: it directly links against libtinfo.so and libncursesw.so (pulls in libtinfow.so).
Comment 6 Sergei Trofimovich gentoo-dev 2018-10-21 11:19:15 UTC
Created attachment 552084 [details, diff]
gdb-8.2-tinfow.patch

This makes SIGSEGV disappear. To avoid pulling in w/non-w libs libreadline will need to do the same.
Comment 7 Larry the Git Cow gentoo-dev 2018-10-21 16:27:44 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=63d949769e25176de0d879cbef2b7cd80348ad0f

commit 63d949769e25176de0d879cbef2b7cd80348ad0f
Author:     Sergei Trofimovich <slyfox@gentoo.org>
AuthorDate: 2018-10-21 16:26:47 +0000
Commit:     Sergei Trofimovich <slyfox@gentoo.org>
CommitDate: 2018-10-21 16:27:36 +0000

    sys-devel/gdb: link against tinfow first, then tinfo. bug #669096
    
    In bug #669096 gdb was directly linked both
    to libtinfo.so.6 and libncursesw.so.6:
        $ lddtree /usr/bin/gdb
        /usr/bin/gdb (interpreter => /lib64/ld-linux-x86-64.so.2)
        libtinfo.so.6 => /lib64/libtinfo.so.6
        libncursesw.so.6 => /lib64/libncursesw.so.6
            libtinfow.so.6 => /lib64/libtinfow.so.6
        ...
    and caused gdb to SIGSEGV at start.
    
    Let's consistently link against *w libraries when both available.
    
    Note: the fix on it's own is not enough:
    - we don't pass include paths to ncursesw libraries
    - libreadline.so.7 is still linked against libtinfo.so.6 in Gentoo
      and needs a separate fix.
    
    But it's enough to make immediate SIGSEGV to go away.
    
    Reported-by: Michał Górny
    Bug: https://bugs.gentoo.org/669096
    Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
    Package-Manager: Portage-2.3.51, Repoman-2.3.11

 sys-devel/gdb/files/gdb-8.2-tinfow.patch |  44 ++++++
 sys-devel/gdb/gdb-8.2-r1.ebuild          | 261 +++++++++++++++++++++++++++++++
 2 files changed, 305 insertions(+)
Comment 8 Sergei Trofimovich gentoo-dev 2018-10-21 16:38:36 UTC
Filed bug #669214 to follow up on readline side.
Comment 9 Sergei Trofimovich gentoo-dev 2018-11-15 23:20:17 UTC
*** Bug 649704 has been marked as a duplicate of this bug. ***