$ 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.
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.
Yeah, the following seems to work: $ LD_PRELOAD=libncurses.so.6 gdb ...but why does your readline link to ncurses?
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 ...
Oh, so it's tinfo that makes readline not link to ncurses. Which is why it crashes for me.
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).
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.
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(+)
Filed bug #669214 to follow up on readline side.
*** Bug 649704 has been marked as a duplicate of this bug. ***
*** Bug 669488 has been marked as a duplicate of this bug. ***
