This is the mail archive of the libc-alpha@sourceware.cygnus.com 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]

Re: libc/1508: symbol conflict due to nss_db.so usage of /lib/libdb.so.3


Hello Andreas.

Andreas Jaeger wrote:
> Is there anything we can do about this problem?
> 
> The obvious solutions are:
> - disable nss_db
> - don't use proprietary software that you can't recompile

Obvious and all true ... but the question is, should the usage 
of the nss db service (or any other process which is supposed to
be transparent) change the behaviour of the libc in a way that the
application can't predict? 

From the application point of view i'd say no. That's the reason
why the various standards have defined a namespace for the libc
and applications so there is a border line.

This does not affect only closed source software but could also
hit an open sw which may not use the current db library version 
for whatever reason (eg. different API).

This specific case is certainly a corner case because the same 
library (which uses reserved name space) is part of libc but also 
common in applications, possibly in different versions.

> Or should this work with glibc 2.2?

Don't know. I can imagine two aproaches:

1. "Don't do that".  The issue could be documented and forgotten.
However i could imagine this or a similar issue could come back 
and hit again.

2. There should be an option to assure that libc components do 
not call other libraries besides the defined interfaces (which
__db_calloc() is not). This would also enforce the libc interfaces 
and sanity. OTOH this would make LD_LIBRARY_PRELOAD less helpful.


Thanks for your great work.
Michael


> Subject: libc/1508: symbol conflict due to nss_db.so usage of /lib/libdb.so.3
> Resent-Date: Fri, 31 Dec 1999 12:00:09 -0500
> Resent-From: gnats@gnu.org (GNATS Management)
> Resent-To: libc-gnats@gnu.org
> Resent-CC: gnats-admin@gnu.org
> Date: Fri, 31 Dec 1999 17:59:25 +0100
> From: Michael Marxmeier <mike@msede.com>
> To: bugs@gnu.org
> 
> >Number:         1508
> >Category:       libc
> >Synopsis:       symbol conflict due to nss_db.so usage of /lib/libdb.so.3
> >Confidential:   no
> >Severity:       serious
> >Priority:       medium
> >Responsible:    libc-gnats
> >State:          open
> >Class:          change-request
> >Submitter-Id:   unknown
> >Arrival-Date:   Fri Dec 31 12:00:04 EST 1999
> >Last-Modified:
> >Originator:     Michael Marxmeier
> >Organization:
> Marxmeier Software AG
> 
> >Release:        libc-2.1.2
> >Environment:
> Host type: i386-suse-linux-gnu
> System: Linux office 2.2.13 #2 Wed Dec 29 23:22:38 CET 1999 i686
> unknown
> Architecture: i686
> 
> Addons: crypt linuxthreads noversion nss-v1
> 
> Build CC: gcc
> Compiler version: egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
> Kernel headers: 2.2.13
> Symbol versioning: yes
> Build static: yes
> Build shared: yes
> Build pic-default: no
> Build profile: yes
> Build omitfp: no
> Build bounded: no
> Build static-nss: no
> Stdio: libio
> 
> >Description:
> I encountered a segfault with the Netscape Messenger server for Linux.
> It failed with a segv.
> I tracked this down to Netscape server using a different version shlib
> of db (/netscape/server4/lib/libdb.so). Now when you have db in
> nsswitch.conf there are two versions of the db library in the
> current process, resulting in all kind of breakage.
> 
> The stack trace below should explain it:
> #1  0x40355fb0 in __db_calloc (num=1, size=156) at os/os_alloc.c:69
> #2  0x4034eeaa in __nss_db_open (fname=0x401ce337
> "/var/db/services.db",
>     type=DB_BTREE, flags=65536, mode=0, dbenv=0x0, dbinfo=0x0,
> dbpp=0x401cf5f0)
>     at db/db.c:159
> #3  0x401cba07 in internal_setent (stayopen=0)
>     at nss_files/../nss_db/db-XXX.c:67
> #4  0x401cbc01 in lookup (key=0xbffff248, result=0x4032febc,
> buffer=0x80c1d78,
>     buflen=1024, errnop=0x8060344) at nss_files/../nss_db/db-XXX.c:173
> #5  0x401cbe8d in _nss_db_getservbyname_r (name=0xbffffa18 "store",
>     proto=0x805b5db "tcp", result=0x4032febc, buffer=0x80c1d78
> "¨»2@¨»2@",
>     buflen=1024, errnop=0x8060344) at nss_files/files-service.c:44
> #6  0x40303819 in __getservbyname_r (name=0xbffffa18 "store",
>     proto=0x805b5db "tcp", resbuf=0x4032febc, buffer=0x80c1d78
> "¨»2@¨»2@",
>     buflen=1024, result=0xbffff2c8) at ../nss/getXXbyYY_r.c:182
> #7  0x40303672 in getservbyname (name=0xbffffa18 "store",
>     proto=0x805b5db "tcp") at ../nss/getXXbyYY.c:123
> #8  0x804ddad in c_main (argc=5, argv=0xbffff874) at serverstart.c:243
> #9  0x80575fd in main (argc=5, argv=0xbffff874) at main_c.c:14
> 
> In this case __db_calloc was taken from the Netscape db shlib.
> 
> >How-To-Repeat:
> Create a program using a shared library with an older/incompatible
> db version and use nss_db.so (eg. getservbyname).
> 
> >Fix:
> Workaround is to remove db entries from /etc/nsswitch.conf.
> 
> IMHO the real fix would be to use a distinct name space for the
> system db library.

-- 
Michael Marxmeier           Marxmeier Software AG
E-Mail: mike@msede.com      Besenbruchstrasse 9
Phone : +49 202 2431440     42285 Wuppertal, Germany
Fax   : +49 202 2431420     http://www.msede.com/

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