Re: slapd segfaults with mdb

[Quanah Gibson-Mount <quanah@zimbra.com>]

--On Monday, January 21, 2013 7:01 PM +0100 Meike Stone 
<meike.stone@googlemail.com> wrote:

> Hello,
>
>
> I play a little with the mdb on a test machine, and imported our db
> from production system.
> (about 1,500,000 entires, 2,5GByte ldif from slapcat)
>
> I took the slapd source from git today, and because of segmentation
> fault, I compiled slapd with debugging symbols.
>
> My configuration is simple:
> --------------------------------------------
> include       /etc/openldap/schema/core.schema
> include       /etc/openldap/schema/cosine.schema
> include       /etc/openldap/schema/inetorgperson.schema
> include       /etc/openldap/schema/yast.schema
> include       /etc/openldap/schema/rfc2307bis.schema
> include       /etc/openldap/schema/my_ldap_attributes.schema
> include       /etc/openldap/schema/my_ldap_ObjectClasses.schema
>
>
> pidfile         /var/run/slapd/slapd.pid
> argsfile       /var/run/slapd/slapd.args
>
>
> sizelimit     -1
> timelimit     300
> disallow      bind_anon
> require        authc
>
> gentlehup    on
> tool-threads 4
>
> serverID      001
>
> ############################
> # mdb database definitions
> ############################
>
> database    mdb
> suffix          "ou=root"
> rootdn         "cn=admin,ou=root"
> rootpw        password
> directory     /var/lib/ldap/ldap.mdb
> loglevel      256
> maxsize    10737418240
>
> envflags     writemap,nometasync
>
> index   objectClass,entryUUID,entryCSN          eq
> index   cn                                      eq,sub
> .
> .
> . some other own indexes here
>
> --------------------------------------------
>
> I started my search via:
>
> /tmp/ol/usr/local/bin/ldapsearch -x -h localhost -w password -D
> cn=admin,ou=root -b'ou=root' '(objectClass=*)' >/dev/null
>
>
> and got in the syslog folloing meassge:
>
> Jan 21 17:50:31 debld02 kernel: [348860.053152] slapd[19394]: segfault
> at 7f760f974ce8 ip 000000000053bea1 sp 00007f738b10a650 error 4 in
> slapd
> [400000+227000]
>
>
>
> Because of this, I configured the kernel to core dump:
>
> sysctl -w kernel.core_pattern=/tmp/core
> sysctl -w kernel.core_uses_pid=1
> sysctl -w kernel.suid_dumpable=2
> ulimit -c unlimited
> ulimit -v unlimited
>
>
> and got the result via:
>
> ~# gdb /tmp/ol/usr/local/libexec/slapd /tmp/core.19386
>
> Core was generated by
> `/tmp/buildforopenldaptechnical/usr/local/libexec/slapd -h ldap:///
> -f /etc/op'.
> Program terminated with signal 11, Segmentation fault.
> # 0  0x000000000053bea1 in mdb_entry_decode (op=0xc3a020,
> data=0x7f738b10a770, e=0x7f738b11a828) at id2entry.c:666
> 666                     a->a_desc = mdb->mi_ads[*lp++];
> (gdb)
>
>
> How can I solve this?

File an ITS (http://www.openldap.org/its/) with a full backtrace of all 
threads from gdb.

--Quanah


--

Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
--------------------
Zimbra ::  the leader in open source messaging and collaboration