GDB generates a SIGSEGV whenever target remote hostname:port command is used (either in .gdbinit or by command). Tracked this down to what appears to be a namespace conflict for timeval_add. Stack trace inserted below. There is a global symbol in libsamba-util.so.0 (timeval_add) and also in libiberty which is part of GDB. This is version Fedora 7.6.1-46.fc19. [fc19 gdb-7.6.1]$ readelf -s /lib64/libsamba-util.so.0 | grep timeval_add 326: 0000003d78a0f0a0 59 FUNC GLOBAL DEFAULT 12 timeval_add@@SAMBA_UTIL_0.0.1 [fc19 gdb-7.6.1]$ readelf -s /lib64/libsamba-util.so.0 | grep timeval_current_ofs 231: 0000003d78a0f130 63 FUNC GLOBAL DEFAULT 12 timeval_current_ofs_msec@@SAMBA_UTIL_0.0.1 343: 0000003d78a0f100 43 FUNC GLOBAL DEFAULT 12 timeval_current_ofs@@SAMBA_UTIL_0.0.1 691: 0000003d78a0f170 59 FUNC GLOBAL DEFAULT 12 timeval_current_ofs_usec@@SAMBA_UTIL_0.0.1 #0 timeval_add (result=0x7fffffffd850, a=0x0, b=0x3d090) at ../../libiberty/timeval-utils.c:57 #1 0x0000003d78a0f124 in timeval_current_ofs () from /lib64/libsamba-util.so.0 #2 0x0000003d71e12b84 in name_query () from /usr/lib64/samba/libgse.so #3 0x00007ffff0d3d489 in _nss_wins_gethostbyname_r () from /lib64/libnss_wins.so.2 #4 0x0000003d3ad0ebd3 in gethostbyname_r@@GLIBC_2.2.5 () from /lib64/libc.so.6 During symbol reading, Child DIE 0xa7383 and its abstract origin 0xa7e56 have different tags. During symbol reading, Child DIE 0xa7383 and its abstract origin 0xa7e56 have different parents. #5 0x0000003d3ad0e316 in gethostbyname () from /lib64/libc.so.6 #6 0x000000000047d69a in net_open (scb=0xdb30d0, name=<optimized out>) at ../../gdb/ser-tcp.c:194 During symbol reading, cannot get low and high bounds for subprogram DIE at 1217621. During symbol reading, Multiple children of DIE 0x12ba07 refer to DIE 0x129485 as their abstract origin. During symbol reading, DW_AT_GNU_call_site_target target DIE has invalid low pc, for referencing DIE 0x12efd3 [in module /home/bruce/rpmbuild/BUILD/gdb-7.6.1/build-x86_64-redhat-linux/gdb/gdb]. #7 0x0000000000637f04 in serial_open (name=<optimized out>, name@entry=0xc2219e "office:1234") at ../../gdb/serial.c:221 #8 0x00000000004a3eac in remote_serial_open (name=0xc2219e "hdev:1234") at ../../gdb/remote.c:3712 #9 remote_open_1 (name=<optimized out>, from_tty=0, target=0xb22160 <remote_ops>, extended_p=0) at ../../gdb/remote.c:4257 #10 0x000000000064127a in execute_command (p=0xc221a8 "4", p@entry=0xc22190 "target remote office:1234", from_tty=0) at ../../gdb/top.c:487 #11 0x0000000000641efb in command_loop () at ../../gdb/top.c:590 #12 0x0000000000641fb9 in read_command_file (stream=stream@entry=0xcd51a0) at ../../gdb/top.c:330 #13 0x00000000004bcc42 in script_from_file (stream=stream@entry=0xcd51a0, file=file@entry=0xd48860 "/home/bruce/.gdbinit") at ../../gdb/cli/cli-script.c:1654 #14 0x00000000004bd366 in source_script_from_stream (stream=0xcd51a0, file=0xd48860 "/home/bruce/.gdbinit") at ../../gdb/cli/cli-cmds.c:545 #15 0x00000000004bf04f in source_script_with_search (file=0xd48860 "/home/bruce/.gdbinit", from_tty=<optimized out>, search_path=0) at ../../gdb/cli/cli-cmds.c:582 #16 0x0000000000584a2e in catch_command_errors (command=0x4bf170 <source_script>, arg=0xd48860 "/home/bruce/.gdbinit", from_tty=from_tty@entry=0, mask=mask@entry=6) at ../../gdb/exceptions.c:573 #17 0x000000000058773f in captured_main (data=data@entry=0x7fffffffe010) at ../../gdb/main.c:958 #18 0x000000000058495a in catch_errors (func=func@entry=0x586430 <captured_main>, func_args=func_args@entry=0x7fffffffe010, errstring=errstring@entry=0x7207cb "", mask=mask@entry=6) at ../../gdb/exceptions.c:546 #19 0x00000000005878d4 in gdb_main (args=args@entry=0x7fffffffe010) at ../../gdb/main.c:1144 #20 0x00000000004543de in main (argc=<optimized out>, argv=<optimized out>) at ../../gdb/gdb.c:34 (top-gdb)
Interesting... I wonder if there might be a general solution for this. I asked the glibc folks: https://sourceware.org/bugzilla/show_bug.cgi?id=16881
Hi Pedro, >> There may be some amount of dlmopen() usage that we can do to ensure the >> implementation loaded modules are hidden from the user modules, but eventually >> the breakage will happen and the only solution is to alter the linkage scope >> (drawing a wall around things) or fix the symbols. Looks like the they are passing the token back to the others to resolve. Bruce
Yeah. Even if there were a good solution for this, there is still the issue that we need to cope with existing systems. So seems like the easiest is for someone rename the libiberty function. Note that libiberty is actually owned by GCC.
Yes - I agree. Since libiberty is owned by GCC, do we need to submit a new bug there and reference this one?
Sure. I'd just suggest making sure the bug description is self contained enough that GCC developers don't actually have to click through the gdb url to understand the issue, otherwise, I suspect nobody will look at it. Thanks.
FYI, this is being discussed on the glibc list: https://sourceware.org/ml/libc-alpha/2016-04/msg00130.html Sounds like the bug should be reported to samba/libnss_wins, to make it follow the symbol namespace guidelines Roland mentioned.
Created attachment 9180 [details] attachment-105459-0.html Yes, I agree but I gave up on resolving after not getting clear owner followed by inactivity. Still happens on FC23 though in case you are interested. Do I need to do anything to push this forward? Looks like the people on the referenced thread would be better equipped to report the bug and resolve. BruceSent from my LG G3, an AT&T 4G LTE smartphone ------ Original message------From: palves at redhat dot com Date: Mon, Apr 11, 2016 3:40 PMTo: bruce.fleming@gmail.com;Subject:[Bug gdb/16818] GDB crashes when using name for target remote hostname:port https://sourceware.org/bugzilla/show_bug.cgi?id=16818--- Comment #6 from Pedro Alves ---FYI, this is being discussed on the glibc list: https://sourceware.org/ml/libc-alpha/2016-04/msg00130.htmlSounds like the bug should be reported to samba/libnss_wins, to make it followthe symbol namespace guidelines Roland mentioned.-- You are receiving this mail because:You are on the CC list for the bug.You reported the bug.
> Yes, I agree but I gave up on resolving after not getting clear owner > followed by inactivity. Still happens on FC23 though in case you are > interested. Thanks. I had seen that, and posted it on the thread I linked above too. > Do I need to do anything to push this forward? Looks like the > people on the referenced thread would be better equipped to report the bug > and resolve. I posted a GDB patch to stop it from exporting timeval_add: https://sourceware.org/ml/gdb-patches/2016-04/msg00244.html Someone should report a bug to libwins_nss.so, pointing them at Roland's mail on NSS modules namespace constrains.
The master branch has been updated by Pedro Alves <palves@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=a4a1c15754d144d14dc48cd8ff62601f977e908c commit a4a1c15754d144d14dc48cd8ff62601f977e908c Author: Pedro Alves <palves@redhat.com> Date: Tue May 3 10:30:51 2016 +0100 Fix PR gdb/16818, workaround Python's forcing of -export-dynamic GDB's use of --dynamic-list to only export the proc-service symbols is broken due to Python's "python-config --ldflags" saying we should link with -export-dynamic, causing us to export _all_ extern symbols anyway. On Fedora 23: $ python-config --ldflags -lpython2.7 -lpthread -ldl -lutil -lm -Xlinker -export-dynamic $ python3.4-config --ldflags -L/usr/lib64 -lpython3.4m -lpthread -ldl -lutil -lm -Xlinker -export-dynamic Having GDB export all its symbols leads to issues such as PR gdb/16818 (GDB crashes when using name for target remote hostname:port), where a GDB symbol unintentionally preempts a symbol in one of the NSS modules glibc loads into the process. NSS modules should not define symbols outside the implementation namespace or the relevant standards, but, alas, that's a longstanding and hard to fix issue. See libc-alpha discussion at: [symbol name space issues with NSS modules] https://sourceware.org/ml/libc-alpha/2016-04/msg00130.html Python should instead be either using GCC's symbol visibility feature or -Wl,--dynamic-list as well, to only export Python API symbols, but, it doesn't. There are bugs open upstream for that: [Use -Wl,--dynamic-list=x.list, not -Xlinker -export-dynamic] http://bugs.python.org/issue10112 [Use GCC visibility attrs in PyAPI_*] http://bugs.python.org/issue11410 But that's taking a long while to resolve. I thought of working around this Python issue by making GDB build with -fvisibility=hidden, as Jan suggests in Python issue 10112, as then Python's "-Xlinker -export-dynamic" has no effect. However, that would need to be done in the whole source tree (bfd, libiberty, etc.), and I think that would break GCC plugins, as I believe those have access to all of GCCs symbols, by "design". So we'd need a new configure switch, or have the libraries in the tree detect which of GCC or GDB is being built, but that doesn't work, because the answer can be "both" with combined builds... So this patch instead works around Python's bug, by simply sed'ing away "-Xlinker -export-dynamic" from the result of python-config.py --ldflags, making -Wl,--dynamic-list work again as it used to. It's ugly, but so is the bug... Note that if -Wl,--dynamic-list doesn't work, we always link with -rdynamic, so static Python should still work. Tested on F23 with --python=python (Python 2.7) and --python=python3.4. gdb/ChangeLog:y 2016-05-03 Pedro Alves <palves@redhat.com> * configure.ac (PYTHON_LIBS): Sed away "-Xlinker -export-dynamic". * configure: Regenerate.
(In reply to Sourceware Commits from comment #9) > The master branch has been updated by Pedro Alves <palves@sourceware.org>: > > https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git; > h=a4a1c15754d144d14dc48cd8ff62601f977e908c > > commit a4a1c15754d144d14dc48cd8ff62601f977e908c > Author: Pedro Alves <palves@redhat.com> > Date: Tue May 3 10:30:51 2016 +0100 > > Fix PR gdb/16818, workaround Python's forcing of -export-dynamic Can this be closed?