deprecate libnsl/libnss_*

  Hi,

I made a first patch to deprecate libnsl and disable the
depending libnss_* modules. It's following the sunrpc code.

I disabled the libnss_* modules, since you cannot install them
in parallel with the new ones. libnsl.so.1 will still be build,
for compatibility reasons and since you can install them in
parallel.

Two problems are still open:
libnsl.so symlink will still be created and you can link against
the library, if you create the .so symlink. No idea how to disable
that.

I haven't used the libc_hidden_nolink_sunrpc macros, since they, 
like for sunrpc, don't work. The problem is, you have to specify the
correct version number for this symbol, but the version number is
different on the different architectures.

  Thorsten
  

On 04/04/2016 03:43 PM, Thorsten Kukuk wrote:

> I made a first patch to deprecate libnsl and disable the
> depending libnss_* modules. It's following the sunrpc code.

What's the replacement for nss_nis?

Thanks,
Florian
  

Hi,

On Mon, Apr 04, Florian Weimer wrote:

> On 04/04/2016 03:43 PM, Thorsten Kukuk wrote:
> 
> > I made a first patch to deprecate libnsl and disable the
> > depending libnss_* modules. It's following the sunrpc code.
> 
> What's the replacement for nss_nis?

Ok, the third time on this list:

libnsl replacing libnsl from glibc/nis:
git: https://github.com/thkukuk/libnsl
tar archives: http://www.linux-nis.org/download/libnsl/

libnss_compat replacing glibc/nis/nss_compat. There are no changes
or functional differences, it's only standalone:
git: https://github.com/thkukuk/libnss_compat
tar archives: http://www.linux-nis.org/download/libnss_compat/

libnss_nis replacing glibc/nis/nss_nis. This version is now
using the new NIS protocol if compiled and linked against
above libnsl and libtirpc:
git: https://github.com/thkukuk/libnss_nis
tar archives: http://www.linux-nis.org/download/libnss_nis/

libnss_nisplus replacing glibc/nis/nss_nisplus. This required
much more changes than for the rest and I thought. It should
work, but I couldn't test it against a NIS+ server.
git: https://github.com/thkukuk/libnss_nisplus
tar archives: http://www.linux-nis.org/download/libnss_nisplus/


Additional, and new:
rpcsvc-proto containing the *.x header files from glibc
not part of tirpc:
git: https://github.com/thkukuk/rpcsvc-proto
  

Thorsten Kukuk <kukuk@suse.de> writes:

> I haven't used the libc_hidden_nolink_sunrpc macros, since they, 
> like for sunrpc, don't work. The problem is, you have to specify the
> correct version number for this symbol, but the version number is
> different on the different architectures.

The version is a macro that expands to the correct version depending on
the architecture.  Use the last version as specified in nis/Versions,
with '.' replaced by '_'.

Andreas.
  

On Mon, Apr 04, Andreas Schwab wrote:

> Thorsten Kukuk <kukuk@suse.de> writes:
> 
> > I haven't used the libc_hidden_nolink_sunrpc macros, since they, 
> > like for sunrpc, don't work. The problem is, you have to specify the
> > correct version number for this symbol, but the version number is
> > different on the different architectures.
> 
> The version is a macro that expands to the correct version depending on
> the architecture.  Use the last version as specified in nis/Versions,
> with '.' replaced by '_'.

This does not work. Example:

xdecrypt()

xdecrypt has in xcrypt.c:
libc_hidden_nolink_sunrpc (xdecrypt, GLIBC_2_1)

In sunrpc/Version it is GLIBC_2.1

On i586 you have xdecrypt@GLIBC_2.1 and you cannot link against
it. But on x86_64, you have xdecrypt@@GLIBC_2.2.5, so you can 
still link against it.

  Thorsten
  

Thorsten Kukuk <kukuk@suse.de> writes:

> xdecrypt has in xcrypt.c:
> libc_hidden_nolink_sunrpc (xdecrypt, GLIBC_2_1)
>
> In sunrpc/Version it is GLIBC_2.1
>
> On i586 you have xdecrypt@GLIBC_2.1 and you cannot link against
> it. But on x86_64, you have xdecrypt@@GLIBC_2.2.5, so you can 
> still link against it.

GLIBC_2_1 expands to GLIBC_2.2.5 on x86_64, which is the first version
for this architecture (see
sysdeps/unix/sysv/linux/x86_64/64/shlib-versions).

Andreas.
  

On 04/04/2016 04:22 PM, Thorsten Kukuk wrote:
> 
> Hi,
> 
> On Mon, Apr 04, Florian Weimer wrote:
> 
>> On 04/04/2016 03:43 PM, Thorsten Kukuk wrote:
>>
>>> I made a first patch to deprecate libnsl and disable the
>>> depending libnss_* modules. It's following the sunrpc code.
>>
>> What's the replacement for nss_nis?
> 
> Ok, the third time on this list:

So we now have code duplication between the external NSS modules and
nss_files and nscd in glibc (on top of the components which are supposed
to be obsolete).  This isn't really desirable.

libtirpc also pulls in a lot of libraries, which makes it less
compatible with in-process NSS modules.  I think it is generally assumed
that the Sun PRC code in glibc was dead, but it is currently not due to
nss_nis, and nss_nis is still relatively widely used.  nss_nis linked
against the current version of libtirpc likely has compatibility
problems due to the additional libraries which it brings in, and the
late loading of libpthread (in response to a NSS request).

We'll prepare things in Fedora for an external nss_nis implementation,
but I'm not sure if it's a feasible approach with what we currently have.

Florian
  

Hi,

On Thu, Apr 07, Florian Weimer wrote:

> So we now have code duplication between the external NSS modules and
> nss_files and nscd in glibc (on top of the components which are supposed
> to be obsolete).  This isn't really desirable.

You mean the parser stuff? Yes, that's duplicate code, but I don't want
to export that with an official interface from glibc.

> libtirpc also pulls in a lot of libraries, which makes it less
> compatible with in-process NSS modules.  I think it is generally assumed
> that the Sun PRC code in glibc was dead, but it is currently not due to
> nss_nis, and nss_nis is still relatively widely used.  nss_nis linked
> against the current version of libtirpc likely has compatibility
> problems due to the additional libraries which it brings in, and the
> late loading of libpthread (in response to a NSS request).

Yes, libtirpc has some more dependencies, because it has rpcsec directly 
included and don't need an extra library try to override glibc functions
for this.
But I don't understand why you see compatibility problemes here, except
that now, with external libnsl and libtirpc, libnss_nis also speaks with
IPv6 NIS servers.
The libnss_nis interface is the same, the interface to the yp_* functions
is the same, except that the external libnsl linked against libtirpc
speaks additional IPv6.

> We'll prepare things in Fedora for an external nss_nis implementation,
> but I'm not sure if it's a feasible approach with what we currently have.

It's the only way to communicate via IPv6.

  Thorsten
  

On Thu, 7 Apr 2016, Florian Weimer wrote:

> libtirpc also pulls in a lot of libraries, which makes it less
> compatible with in-process NSS modules.  I think it is generally assumed

If it's visible to an application what libraries were loaded by an NSS 
module, I'd consider that to be a bug (bug 16881, I think) - NSS modules 
should be loaded in such a way that this is not visible.

> problems due to the additional libraries which it brings in, and the
> late loading of libpthread (in response to a NSS request).

I think we need to fix the issues in libc that break with late loading of 
libpthread, so that it can be properly transparent to the application 
whether any modules it loads use threads or not.  (Bug 16628, I think; 
also bug 18192 relates to dlopen of libpthread, and there may be other 
such bugs filed as well.)
  

On 04/07/2016 05:25 PM, Joseph Myers wrote:
> On Thu, 7 Apr 2016, Florian Weimer wrote:
> 
>> libtirpc also pulls in a lot of libraries, which makes it less
>> compatible with in-process NSS modules.  I think it is generally assumed
> 
> If it's visible to an application what libraries were loaded by an NSS 
> module, I'd consider that to be a bug (bug 16881, I think) - NSS modules 
> should be loaded in such a way that this is not visible.

I'm not sure if the general case is solvable.  Some libraries want to be
loaded only once, others have to be loaded multiple times in different
versions, and so on.  But I expect we can provide additional knobs to
improve the situation.

>> problems due to the additional libraries which it brings in, and the
>> late loading of libpthread (in response to a NSS request).
> 
> I think we need to fix the issues in libc that break with late loading of 
> libpthread, so that it can be properly transparent to the application 
> whether any modules it loads use threads or not.  (Bug 16628, I think; 
> also bug 18192 relates to dlopen of libpthread, and there may be other 
> such bugs filed as well.)

Agreed, this problem seems tractable.

Florian
  

> If it's visible to an application what libraries were loaded by an NSS 
> module, I'd consider that to be a bug (bug 16881, I think) - NSS modules 
> should be loaded in such a way that this is not visible.

Bug 16881 is not entirely clear on what it's talking about.  On the face of
it, it sounds like a problem that could only arise if something were using
RTLD_GLOBAL.  If that's all it's talking about, then that should already
not be an issue.

The broader issue is much harder to address.  Short of NSS modules being
loaded via a dlmopen-style mechanism, dependencies of NSS modules that are
also themselves dependencies of things used by the application itself
(including indirectly via other libraries it uses) will be loaded exactly
once and so depending on their initializer code and module-global state,
that might very well be visible to the application.
  

On 04/08/2016 07:39 PM, Roland McGrath wrote:
>> If it's visible to an application what libraries were loaded by an NSS 
>> module, I'd consider that to be a bug (bug 16881, I think) - NSS modules 
>> should be loaded in such a way that this is not visible.
> 
> Bug 16881 is not entirely clear on what it's talking about.  On the face of
> it, it sounds like a problem that could only arise if something were using
> RTLD_GLOBAL.  If that's all it's talking about, then that should already
> not be an issue.

gdb has a timeval_add symbol, and none of the direct dependencies 
of gdb define a conflicting symbol.  However, gdb calls gethostbyname, 
and that, due to some internal implementation detail of glibc, 
dynamically loads a module which does have a global symbol of the 
same name, which ended up unintentionally overridden by gdb's symbol.

The bug was about seeing if it'd be possible for internal
details of the implementation, and here I'm calling implementation/libnss
loaded modules as such, not to cause namespace pollution in symbols
not in the implementation namespace, nor reserved by the
relevant standards, vs applications having to avoid the issue
themselves, by renaming their symbols.

AFAICS, gdb has not renamed the symbol, and I'm not the one
who tripped on it in the first place, so I'm not sure
whether this particular instance of the bug was fixed some
other way.

Let me know whether it's still not clear.
  

[I've changed the subject line to reflect what this thread is actually
talking about now, and trimmed the CC of people I'm sure are on the list.]

> gdb has a timeval_add symbol, and none of the direct dependencies 
> of gdb define a conflicting symbol.  However, gdb calls gethostbyname, 
> and that, due to some internal implementation detail of glibc, 
> dynamically loads a module which does have a global symbol of the 
> same name, which ended up unintentionally overridden by gdb's symbol.

I see.  That was not clear to me from the bug, but perhaps I did not
read it closely enough.  It would certainly be clearer if the bug
included a small reproducer program rather than just talking about a
case with gdb.

I'd call this just a simple bug in the NSS module in question.  We can
fix those without addressing the broader issue about NSS modules in
the abstract.  This is just a "normal" case of a name space violation,
which is something that we identify and fix in libc as a matter of
course.

For name space issues in the core libraries, we catch them with our
"linknamespace" tests.  These are exhaustive in the sense of covering
all possible name space violations in all the library code examined.
But they only test static linking cases.  For most of our code, this
is a sufficient proxy to catch problems that would arise in shared
library cases just because the static-library and shared-library code
are close enough to being compiled from the same sources.  It's easy
to test this way for static linking precisely because it's static
linking, so all the dependency arcs are travelled at link time.

For DSOs in general, it's hard to find these issues without false
positives.  Consider libc.so itself: it defines the nonstandard symbol
strfry, but that is OK since nothing (in the transitive closure of
dependencies from functions in standardized name spaces) refers to
strfry.  Your application's strfry will take precedence over libc's,
but that's OK because nobody will be making calls to libc's strfry.
The naive approach of just looking for nonstandard symbols will see
strfry in the DSO and report a false-positive error.  In the static
linking linknamespace tests, that problem doesn't arise because the
linker is implicitly doing the fine-grained call-graph analysis as a
by-product of linking and so it will see nothing leading to strfry.

We could theoretically implement some sufficient testing for this when
building the DSOs.  That is, look at each object file going into the
DSO and construct the static call graph to verify that no arc crosses
from a more-restricted name space into a less-restricted one.  That
doesn't seem like a huge amount of work, but I'm not sure it would
catch anything in practice that we don't already catch with our static
linking linknamespace tests.

For modules that are programmatically loaded at runtime, the problem
is a bit different.  (That is, NSS modules, iconv modules, libcidn,
and libgcc_s.)  In the general case, it's difficult or impossible to
know what library code (and hence what name space constraint
environments) enters what loaded module code (and hence what parts of
the DSO's static call graph are relevant).  But for the modules we
actually use, it's easy enough to define some conservative rules.

For NSS modules, I think all the library entry points that can lead to
entering NSS module code are POSIX.1 symbols or GNU/misc extensions.
Being conservative, we can ignore the latitude available when the
entry point in question is a GNU extension and just act as if every
entry into an NSS module is from a POSIX.1 function.  If that's true,
then we can just make the blanket statement that NSS modules can refer
only to the POSIX.1, ISO C, and implementation name spaces.  This is
something we can test statically in the built module itself, though if
it has other DT_NEEDED dependencies then testing those correctly might
be difficult (to do without false positives).

I just eyeballed the symbol table of libnss_files.so, which is the NSS
module that is simplest and so seems the least likely to have
problematic symbol dependencies.  But even that has one real bug and
one false positive.  The real bug is calling inet_network, which is a
nonstandard symbol reachable via the POSIX.1 getnet* functions.  The
false positive is xdecrypt, which every NSS module seems to use in its
implementation of the getsecretkey backend--but getsecretkey is a
nonstandard function in the same name space category as xdecrypt, so
that's actually fine but looks bad to the naive test I just suggested
above.  (Arguably we ought to change the NSS protocol for getsecretkey
so that the module returns the "raw" value and libc calls xdecrypt.
Then at least it would become possible to write a fully-functioning
NSS module that passes the naive name space test.)

For less trivial modules that use other DSOs to do their work, this
can be a very hard problem.  In the general case, it could require
name space discipline for all of the reachable code.  When the DSOs in
question are general-purpose things (which off hand seems like the
only reason there would be dependent DSOs) then they'd be exporting
symbols in the implementation name space (_*), which is directly
contrary to general advice.  

In many common circumstances, dynamic linking rules and symbol
versions will mitigate the problem substantially.  That is, an
application will not have its miscellaneous global symbols in its
dynamic symbol table, only the ones that were found at link time to
override the same-named symbol defined in some directly-linked DSO
(such as libc).  e.g., even if an application had a function called
yp_match this would not be a problem if the application didn't itself
also link against -lnsl (or another library using that symbol
name)--so its yp_match won't override the one that libnss_nis calls.
It might even be the case that it wouldn't override yp_match if the
application was linked against a different library providing yp_match,
that library uses symbol versioning, and its SONAME and/or symbol
version for yp_match do not match libnsl.so.1's.  (That is, the
application's dynamic symbol table does contain yp_match, but its
symbol version binding is not for libnsl.so.1's version.)  But I'm
frankly unsure how symbol version binding affects all these cases.
I'm pretty sure that there are cases where some unintended overriding
could happen (maybe if the other DSO in question doesn't use symbol
versioning?).  I'm quite sure that if an application directly links
against -lnsl and intentionally overrides its yp_match symbol, that
this will indeed intercept calls from libnss_nis.so (and whether that
counts as intended or not is a complex question).

This morass might lead one to want to use dynamic linking name spaces
(dlmopen) for NSS modules.  But that is its own whole can of worms
that might well wind up being worse in totally different ways.

> AFAICS, gdb has not renamed the symbol, and I'm not the one
> who tripped on it in the first place, so I'm not sure
> whether this particular instance of the bug was fixed some
> other way.

The symbol timeval_add does not appear anywhere in the libc sources,
including ChangeLog files.  So I tend to doubt that this symbol name
was used by any libc code in the past either.  That suggests that the
case you hit was in a third-party NSS module.  Obviously we can't
ourselves do anything directly about the quality of third-party
modules.  But we could potentially provide a tool to vet third-party
modules for our name space rules.


Thanks,
Roland
  

On 04/09/2016 12:07 AM, Roland McGrath wrote:

> This morass might lead one to want to use dynamic linking name spaces
> (dlmopen) for NSS modules.  But that is its own whole can of worms
> that might well wind up being worse in totally different ways.

ISTR some work a while ago to improve dlmopen support, make it
match Solaris behavior more closely.  Seems like it'd be the
ideal solution.

Alternatively, in the "always possible to solve with indirection" vein,
fork and load third-party modules in a separate process, with some
simple RPC to return results back to parent.

> 
>> AFAICS, gdb has not renamed the symbol, and I'm not the one
>> who tripped on it in the first place, so I'm not sure
>> whether this particular instance of the bug was fixed some
>> other way.
> 
> The symbol timeval_add does not appear anywhere in the libc sources,
> including ChangeLog files.  So I tend to doubt that this symbol name
> was used by any libc code in the past either.  That suggests that the
> case you hit was in a third-party NSS module.  Obviously we can't
> ourselves do anything directly about the quality of third-party
> modules.  But we could potentially provide a tool to vet third-party
> modules for our name space rules.

The original report showed:

#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
#5  0x0000003d3ad0e316 in gethostbyname () from /lib64/libc.so.6
...

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.

 $ readelf -s /lib64/libsamba-util.so.0 | grep timeval_add
    534: 000000000000ed20    63 FUNC    GLOBAL DEFAULT   12 timeval_add@@SAMBA_UTIL_0.0.1

 $ readelf -s /lib64/libnss_wins.so.2 | grep gethostbyname_r
     36: 0000000000001040  1435 FUNC    GLOBAL DEFAULT   12 _nss_wins_gethostbyname_r@@NSS_WINS_2

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>".

Thanks,
Pedro Alves
  

On 04/08/2016 09:49 PM, Pedro Alves wrote:

> AFAICS, gdb has not renamed the symbol, and I'm not the one
> who tripped on it in the first place, so I'm not sure
> whether this particular instance of the bug was fixed some
> other way.

The library dependencies of nss_wins were cut down considerably (similar 
to the transition from nss_ldap and nss_ldapd).  Additionally, it 
appears to be broken in current Fedora because a required DSO cannot be 
located on the default library path.

Florian
  

> ISTR some work a while ago to improve dlmopen support, make it
> match Solaris behavior more closely.  Seems like it'd be the
> ideal solution.

It is a large can of worms that is very far from "ideal".  I won't go into
the details here, because it would be a very large digression.  Suffice it
to say that it is not part of any near-term (or even medium-term) solution.

> The original report showed:
> 
> #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
> #5  0x0000003d3ad0e316 in gethostbyname () from /lib64/libc.so.6
> ...

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.  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.

> 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.

This is a very complex and subtle set of problems that we are not going to
resolve generically in libc any time soon.  So for now, anybody providing
third-party NSS modules needs to understand the issues.  The simplest
workaround today is just to advise people to use nscd when using any
third-party modules in nsswitch.conf.
  

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