Bug 16818 - GDB crashes when using name for target remote hostname:port
Summary: GDB crashes when using name for target remote hostname:port
Status: NEW
Alias: None
Product: gdb
Classification: Unclassified
Component: gdb (show other bugs)
Version: 7.6
: P2 critical
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-04-07 21:56 UTC by bruce.fleming
Modified: 2016-05-16 18:09 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed: 2014-04-09 00:00:00


Attachments
attachment-105459-0.html (891 bytes, text/html)
2016-04-12 00:04 UTC, bruce.fleming
Details

Note You need to log in before you can comment on or make changes to this bug.
Description bruce.fleming 2014-04-07 21:56:49 UTC
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)
Comment 1 Pedro Alves 2014-04-29 12:20:10 UTC
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
Comment 2 bruce.fleming 2014-05-01 18:58:05 UTC
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
Comment 3 Pedro Alves 2014-05-01 19:01:15 UTC
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.
Comment 4 bruce.fleming 2014-05-02 16:28:14 UTC
Yes - I agree.  Since libiberty is owned by GCC, do we need to submit a new bug there and reference this one?
Comment 5 Pedro Alves 2014-05-13 17:08:55 UTC
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.
Comment 6 Pedro Alves 2016-04-11 22:40:19 UTC
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.
Comment 7 bruce.fleming 2016-04-12 00:04:42 UTC
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.
Comment 8 Pedro Alves 2016-04-12 15:31:09 UTC
>     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.
Comment 9 cvs-commit@gcc.gnu.org 2016-05-03 09:42:53 UTC
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.