Your message dated Mon, 13 Sep 2010 00:37:56 -0700
with message-id <[email protected]>
and subject line Re: [slapd] segfault possibly caused by libdb-4.6.so
has caused the Debian Bug report #528723,
regarding [slapd] segfault possibly caused by libdb-4.6.so
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
528723: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=528723
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: slapd
Version: 2.4.11-1
Severity: normal
--- Please enter the report below this line. ---
Hi,
I installed a lenny system via an official netinstall cd. Then I upgraded the
system to testing and installed kolabd and kolab-webadmin.
Without further manual configuration changes, slapd segfaults during the first
request (e.g. triggered by ldapsearch).
I installed slapd-dbg and started slapd via gdb. Attached you find the gdb log
and the slapd.conf file, as well as the used kolab2.schema file.
My versions of db4.6 (it was mentioned in the gdb output):
ii db4.6-util 4.6.21-13
ii libdb4.6 4.6.21-13
I hope, this helps you to reproduce the segfault.
thanks for your time,
Lars
--
gpg key: https://systemausfall.org/schluessel/lars-devel.0.asc
Starting program: /usr/sbin/slapd -d 2 -g openldap -u openldap -f /etc/ldap/slapd.conf
[Thread debugging using libthread_db enabled]
[New Thread 0xb7a586c0 (LWP 31809)]
[New Thread 0xb5113b90 (LWP 31812)]
[Thread 0xb5113b90 (LWP 31812) exited]
[New Thread 0xb5113b90 (LWP 31813)]
[New Thread 0xb4511b90 (LWP 31814)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb4511b90 (LWP 31814)]
0xb7b9afd3 in strchrnul () from /lib/i686/cmov/libc.so.6
Thread 4 (Thread 0xb4511b90 (LWP 31814)):
#0 0xb7b9afd3 in strchrnul () from /lib/i686/cmov/libc.so.6
#1 0xb7b5e81b in vfprintf () from /lib/i686/cmov/libc.so.6
#2 0xb7b63590 in ?? () from /lib/i686/cmov/libc.so.6
#3 0xb7b5ea4e in vfprintf () from /lib/i686/cmov/libc.so.6
#4 0xb79bba34 in __db_errfile () from /usr/lib/libdb-4.6.so
#5 0xb79c599f in ?? () from /usr/lib/libdb-4.6.so
#6 0x084cc808 in ?? ()
#7 0x00000000 in ?? ()
Thread 3 (Thread 0xb5113b90 (LWP 31813)):
#0 0xb7f4b424 in __kernel_vsyscall ()
#1 0xb7c028d6 in epoll_wait () from /lib/i686/cmov/libc.so.6
#2 0x08073227 in slapd_daemon_task (ptr=0x0)
at /build/buildd/openldap-2.4.11/servers/slapd/daemon.c:2281
#3 0xb7c864e5 in start_thread () from /lib/i686/cmov/libpthread.so.0
#4 0xb7c0210e in clone () from /lib/i686/cmov/libc.so.6
Thread 1 (Thread 0xb7a586c0 (LWP 31809)):
#0 0xb7f4b424 in __kernel_vsyscall ()
#1 0xb7c86b67 in pthread_join () from /lib/i686/cmov/libpthread.so.0
#2 0xb7f0ed94 in ldap_pvt_thread_join () from /usr/lib/libldap_r-2.4.so.2
#3 0x08070043 in slapd_daemon ()
at /build/buildd/openldap-2.4.11/servers/slapd/daemon.c:2643
#4 0x0805deee in main (argc=9, argv=0xbfe68eb4)
at /build/buildd/openldap-2.4.11/servers/slapd/main.c:948
#0 0xb7b9afd3 in strchrnul () from /lib/i686/cmov/libc.so.6
The program is running. Exit anyway? (y or n)
kolab2.schema.bz2
Description: application/bzip
slapd.conf
Description: Binary data
signature.asc
Description: PGP signature
--- End Message ---
--- Begin Message ---
Version: 2.4.23-1
Since slapd has never linked against libdb4.6, the only possible
explanations I see for this are:
- an invalid LD_PRELOAD value is set in your environment;
- one or more of the slapd modules on your system is corrupted with a local
copy linked against the wrong libdb; or
- your sasl configuration results in libsasldb being loaded, which does
link against libdb4.6.
The only one of these that would be a bug in openldap is the last. In any
case, it's definitely now fixed for squeeze, where everything links against
a version of BDB which uses symbol versioning; so I'm marking this bug as
resolved there.
Since db4.2 in lenny doesn't use symbol versioning, it's impractical to
fully resolve this bug for that release. I'd advise fixing your SASL config
to not use sasldb.
Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
[email protected] [email protected]
signature.asc
Description: Digital signature
--- End Message ---
