| Summary: | sys-devel/gdb-8.2: segmentation fault in termattrs_sp() from libncursesw | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Michał Górny <mgorny> |
| Component: | Current packages | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | admnd, base-system, hazelnusse, slyfox, thibaut.sautereau |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=669488 https://bugs.gentoo.org/show_bug.cgi?id=682386 |
||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | gdb-8.2-tinfow.patch | ||
|
Description
Michał Górny
2018-10-20 21:14:25 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.
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. *** |