libc/1508: symbol conflict due to nss_db.so usage of /lib/libdb.so.3
Mark Kettenis
kettenis@wins.uva.nl
Tue Jan 4 03:42:00 GMT 2000
From: Andreas Jaeger <aj@suse.de>
Date: 04 Jan 2000 11:10:27 +0100
Michael, please pay attention and provide us with the information I'm
requesting below.
MM> Don't know. I can imagine two aproaches:
MM> 1. "Don't do that". The issue could be documented and forgotten.
MM> However i could imagine this or a similar issue could come back
MM> and hit again.
MM> 2. There should be an option to assure that libc components do
MM> not call other libraries besides the defined interfaces (which
MM> __db_calloc() is not). This would also enforce the libc interfaces
MM> and sanity. OTOH this would make LD_LIBRARY_PRELOAD less helpful.
__db_calloc is not called directly from glibc at all. Have a look at
the stacktrace and the source. nss_db_open is an alias for db_open -
glibc just calls db_open in nss_db/db-XXX.c
More correctly, db_open is a weak alias for __nss_db_open and we only
call __nss_db_open from nss_db module. The name __nss_db_open is
clearly within the namespace owned by glibc, nobody else should be
messing with __nss_ prefixed names! This basically should have the
effect of approach 2.
That's why I don't understand what's happening here. The symbol
__db_calloc has only local scope in the libdb.so.3 that comes with
glibc. So there is no way that a call to __nss_db_open in our
lidb.so.3 could end up in the __db_calloc in Netscape's libdb.so. In
order to make sure this is really true, Michael, could you send us the
output of:
$ nm /lib/libdb.so.3 | grep __db_calloc
If the above if true, this means, that either:
* The segmentation fault is not related to the two different db libs
(or at least not in the way Michael suggests).
* Somehow, the call to __nss_db_open ends up in Netscape's libdb.so.
That means that either Netscape did something incredibly stupid:
They distributed their libdb.so with a symbol named __nss_db_open.
To check this, Michael, could you send us the output of:
$ nm /netscape/server4/lib/libdb.so | grep __nss_db_open
Or the dynamic linker messes things up by not only relocating
db_open to the db_open in Netscape's libdb.so but also pointing
__nss_db_open to db_open in Netscape's libdb.so.
Mark
More information about the Libc-alpha
mailing list