bug-glibc
[Top][All Lists]
Advanced

[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

Hi,
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
occurs.

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


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


Questions:
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?


Srikrishnan
________

Hi,
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
"mapped".

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

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.

Srikrishnan


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

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


Thanks,
Srikrishnan







_______________________________________________
Bug-glibc mailing list
address@hidden
http://mail.gnu.org/mailman/listinfo/bug-glibc








reply via email to

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