This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: symbol name space issues with NSS modules


On 04/11/2016 11:09 PM, Roland McGrath wrote:

> OK, this is indeed enough to know that libnss_wins.so.2 is at fault.
> That module, of course, is not part of glibc.
> 
>> Frame #0 is GDB's symbol, which is what overrode a symbol of the same
>> name in libsamba-util.so.0.  On Fedora 23, I still see the same symbols
>> as the OP saw.
> 
> Clearly GDB was built with -rdynamic, which is an unusual thing to do.
> Normally a symbol like timeval_add would not be in an executable's .dynsym
> and so would never affect DSOs.  
> 
> The usual reason to use -rdynamic is so that dlopen'd modules in some sort
> of plug-in system can access some of the main executable's symbols.  

Yes, gdb needs to export the proc-service symbols for libthread_db.so.

> But
> -rdynamic is a very big and sloppy hammer.  I would certainly recommend
> exporting a specific intended ABI rather than every global function in gdb.

GDB already know to do that:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=gdb/proc-service.list;h=fc3fc910915fa468941017fb112be011f735a870;hb=2d059a33d890c017c8105b102a6b56ccbd6128b2

However, unfortunately the -Wl,--dynamic-list list needs to be disabled
when GDB is linked with Python, which it normally is:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=gdb/configure.ac;h=70452d3ff056e11b533988595db9b3c62baf94f7;hb=2d059a33d890c017c8105b102a6b56ccbd6128b2#l1704

Looks like that's only needed for static Python though, so maybe that
check is broken.

> 
>> libnss_wins.so.2 is provided by:
>>
>>  $ rpm -qf /lib64/libnss_wins.so.2
>>  samba-winbind-modules-4.3.6-0.fc23.x86_64
>>
>> I already had those installed, most probably just because I installed
>> Samba.
>>
>> I don't know how to make gethostname end up calling into this
>> wins nss module.  It doesn't for me, but I assume that remote debugging
>> with gdb is still broken for anyone for who it does.  All it takes to
>> get to that gethostname call is "target remote <host>:<port>".
> 
> /etc/nsswitch.conf controls which modules will be called.
> A line like "hosts: files wins dns" is probably what was being used.

Thanks.  Adding wins to my /etc/nsswitch.conf file indeed immediately
broke gdb/master:

$ gdb -ex "tar remote foo:1111"
...
(top-gdb) bt
#0  0x00000000008ee3dd in timeval_add (result=0x7fffffffcd30, a=0x0, b=0x3d090) at /home/pedro/gdb/mygit/src/libiberty/timeval-utils.c:56
#1  0x00007fffe9043da4 in timeval_current_ofs () from /lib64/libsamba-util.so.0
#2  0x00007fffe87abf94 in name_query () from /usr/lib64/samba/libgse-samba4.so
#3  0x00007fffe92a0527 in _nss_wins_gethostbyname_r () from /lib64/libnss_wins.so.2
#4  0x00007ffff5792a3a in __gethostbyname_r (name=name@entry=0x7fffffffd0e0 "foo", resbuf=resbuf@entry=0x7ffff5a3c240 <resbuf>, 
    buffer=0x1623f80 "\274\245\336", <incomplete sequence \314>, buflen=1024, result=result@entry=0x7fffffffd078, h_errnop=h_errnop@entry=0x7fffffffd074)
    at ../nss/getXXbyYY_r.c:266
#5  0x00007ffff57921be in gethostbyname (name=0x7fffffffd0e0 "foo") at ../nss/getXXbyYY.c:116

Thanks,
Pedro Alves


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]