[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

glibc-2.3.1: Segfault when nis compiled with "- static"

From: Srikrishnan Sundararajan
Subject: glibc-2.3.1: Segfault when nis compiled with "- static"
Date: Thu, 3 Apr 2003 20:57:01 +0530

I'd tried to be a bit more specific than before, I would appreciate if any
one could help me with this.

Hello Thorsten,
May I request you to have a look at the following and let me know if you
have any thoughts/suggestions?

I have compiled and am using glinc-2.3.1. I am compiling and running my
test program on the sale machine and same glibc version. While using NIS in
compat modeand statically compiling my program calling getpwuid, I observe
the following:

1. When glibc is built without static NSS (default) using only
--prefix-/usr --enable-add-ons=linuxthreads,
dl_open of libnss_compat.so is done, then dl_sym is called for
"libnss-compat_getpwuid_r". When the address returned is called, segfault

2. 1. When glibc is built with static NSS (by explicity adding
--enable-static-nss=yes  along with --prefix-/usr
--enable-add-ons=linuxthreads, and comping the program as follows:
gcc -g -o getpws getpw.c -static -Wl,--start-group -lc -lnss-files -ldns
-lresolv -wl,--end-group

Here, I observe that there is no libnss_compat.a or an equivalent static
library. Therefore, when nss_service_name for compat fails, it tries for
files, and checks /etc/passwd and as the userid is not found, it returns

In both the above cases, dynamically compiled program calls dl_open for
libnss_compat.so and returns the correct userID from the NIS Server.

1. In case 1, why does segfault occur? Is this expected behaviour?

2. In case 2, why is there a way to compile all the nis libraries
statically, in addtion to those in nss directory?


Here is some additional info and few more questions for my earlier post.
1. I am compiling my application calling getpwuid with "- static".  I
understand that while using nss, even a statically linked binary calls a
few shared libraries. When I observe /proc/<pid>/maps I find that even
libc.so, ld.so etc get "mapped". Upon trying to disassemble, I find that
they are not really present in the address where they are shown to be

This also seems to be the reason, why when I call getpwuid, using NIS
"compat" mode, attempt to call _nss_compat_getpwuid_r in libnss_compat.so
results in segfault(SIGSEGV), as it is not in the address returned by

2. Is it that segfault is expected to occur in the above scenario? Is the
only way out to compile glibc with "static-nss" option?

Please note that I had been trying to compile and run my application using
the same glibc version (glibc-2.3.1) on the same machine (I am using the
same glibc which  I compiled on the same machine. )

While running the application after dynamically linking, no problems occur.

Any help would be appreciated.


It is the same problem as in the following post:
 static binary doing getpwuid() or such
      + "passwd: compat" in /etc/nsswitch.conf
      + "address@hidden::::::" in /etc/passwd
      = crash.

I am used my compiled version of glibc-2.3.1 on Linux/i386. I am compling
with "-static" and executing my program on the same machine(NIS client with
compat mode). The test program just calls getpwuid, I get a segfault.

I have not be able to see any proper solution while looking at the previous
posts. Upon using gdb, I found that DB_LOOKUP_FCT is called. Here
nss_compat is loaded using dl_open and the address for the function is
nss_compat_getpwuid_r is looked up (nss_lookup_function -> lib_dlsym ->

Then DL_CALL_FCT is called with the function address returned. This in turn
calls dl_mcount from elf/dl-profstub.c:42. Soon, segfault occurs.

 /proc/<pid>/maps shows that the nss_compat has been mapped around the
place for which I get "??" in backtrace after the segfault.

1. Is this a known problem, has it been fixed?
2. I am compling as well as and executing the program on the same machine
with the same glibc-2.3.1?
Any other help or suggestions in zeroing in on the problem would be


Bug-glibc mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]