[Date Prev][Date Next] [Chronological] [Thread] [Top]

slapd/Openldap-2.0.18 core dump in Redhat 7.1

Hi there,

We have been running slapd of openldap-2.0.18 for months. It appears stable.
It didn't crash.

Recently since the load become high, 90% cpu is used by slapd daemons, we
changed indice and rebuilt the indice by 'slapindex' command.
Then slapd crashed after a few hours. The crash happened a few times since then.
Attached is gdb trace from the core file.

Your help is greatly appreciated.

Lige Zhou
RR Enterprises Inc.


Loaded symbols for /usr/lib/sasl/libplain.so
#0 __strtol_internal (nptr=0x40dbd5d0 "\003", endptr=0x41b33628, base=15, group=1102263848)
at eval.c:36
36 eval.c: No such file or directory.
in eval.c
(gdb) bt
#0 __strtol_internal (nptr=0x40dbd5d0 "\003", endptr=0x41b33628, base=15, group=1102263848)
at eval.c:36
#1 0x080992dd in ber_int_sb_write (sb=0x40dbd5d0, buf=0x41b33628, len=15) at sockbuf.c:428
#2 0x08097797 in ber_flush (sb=0x40dbd5d0, ber=0x41b33038, freeit=0) at io.c:229
#3 0x08059482 in send_ldap_ber (conn=0x403cafd4, ber=0x41b33038) at result.c:201
#4 0x08059788 in send_ldap_response (conn=0x403cafd4, op=0x81a9650, tag=101, msgid=365, err=0,
matched=0x0, text=0x0, ref=0x0, resoid=0x0, resdata=0x0, sasldata=0x0, ctrls=0x0)
at result.c:320
#5 0x08059f15 in send_search_result (conn=0x403cafd4, op=0x81a9650, err=0, matched=0x0,
text=0x0, refs=0x0, ctrls=0x0, nentries=1) at result.c:549
#6 0x08073872 in ldbm_back_search (be=0x80da170, conn=0x403cafd4, op=0x81a9650,
base=0x41b506b0 "dc=amtelecom, dc=net", nbase=0x41c05298 "DC=AMTELECOM,DC=NET", scope=2,
deref=0, slimit=-2, tlimit=10, filter=0x41c052b8,
filterstr=0x41bd5338 "(&(objectClass=posixAccount)(uid=douglaslan))", attrs=0x41c05398,
attrsonly=0) at search.c:345
#7 0x08050f13 in do_search (conn=0x403cafd4, op=0x81a9650) at search.c:278
#8 0x0804fbe4 in connection_operation (arg_v=0x8276400) at connection.c:831
#9 0x08084a81 in ldap_int_thread_pool_wrapper (pool=0x80b87c0) at tpool.c:379
#10 0x401dac6f in pthread_start_thread (arg=0x43002be0) at manager.c:284