[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Updates make slapd prone to crash (ITS#1358)
Full_Name: Robert J Gautier
Version: 2.0.15
OS: Red Hat Linux 7.1
URL: http://www.ateb.co.uk/openldap/robert-gautier-012809.tgz
Submission from: (NULL) (62.49.221.78)
Following a large number of updates to our database, slapd is prone to crashing
when reading values back. We load a database of about 3800 users with slapadd,
then modify a single attribute of every 'person'. Then slapd is likely to
crash
on reading values back. Restarting slapd seems to make it work again. Just
prior
to the crash, slapd will give incorrect query results.
Here is a traceback that is typical:
(gdb) where
#0 __libc_free (mem=0x804) at malloc.c:3036
#1 0x08098b85 in ber_bvfree (bv=0x93f4fc0) at memory.c:369
#2 0x08098bc8 in ber_bvecfree (bv=0x94b3288) at memory.c:390
#3 0x080539a8 in attr_free (a=0x949b878) at attr.c:33
#4 0x080539d0 in attrs_free (a=0x949b878) at attr.c:44
#5 0x0805455a in entry_free (e=0x97956c0) at entry.c:285
#6 0x0807706a in cache_add_entry_rw (cache=0x80ddaec, e=0x8c157d0, rw=0)
at cache.c:353
#7 0x0807bde6 in id2entry_rw (be=0x80dd4a8, id=143, rw=0) at id2entry.c:158
#8 0x08073682 in ldbm_back_search (be=0x80dd4a8, conn=0x402bf4bc,
op=0xb03e6a8, base=0xaf9f170 "dc=ne-worcs,dc=ac,dc=uk",
nbase=0x93016f0 "DC=NE-WORCS,DC=AC,DC=UK", scope=2, deref=2, slimit=-142,
tlimit=-1, filter=0x8f86ec8, filterstr=0x92ec618 "(objectClass=person)",
attrs=0x9377cf0, attrsonly=0) at search.c:205
#9 0x0805137f in do_search (conn=0x402bf4bc, op=0xb03e6a8) at search.c:278
#10 0x08050088 in connection_operation (arg_v=0x9329900) at connection.c:831
#11 0x08085378 in ldap_pvt_thread_pool_submit (pool=0x80baf98,
start_routine=0x804ff28 <connection_operation>, arg=0x9329900)
at thr_stub.c:159
#12 0x08050ae5 in connection_op_activate (conn=0x402bf4bc, op=0xb03e6a8)
at connection.c:1234
#13 0x08050838 in connection_input (conn=0x402bf4bc) at connection.c:1124
#14 0x080504b5 in connection_read (s=7) at connection.c:1019
#15 0x0804e79b in slapd_daemon_task (ptr=0x0) at daemon.c:1181
#16 0x080852cc in ldap_pvt_thread_create (thread=0xbffff8b0, detach=0,
start_routine=0x804d7c8 <slapd_daemon_task>, arg=0x0) at thr_stub.c:48
#17 0x0804e994 in slapd_daemon () at daemon.c:1247
#18 0x0804c35a in main (argc=3, argv=0xbffff96c) at main.c:443
#19 0x40197e5e in __libc_start_main (main=0x804bd20 <main>, argc=3,
ubp_av=0xbffff96c, init=0x804ae00 <_init>, fini=0x809c920 <_fini>,
rtld_fini=0x4000d3c4 <_dl_fini>, stack_end=0xbffff95c)
at ../sysdeps/generic/libc-start.c:129
(gdb) up
#1 0x08098b85 in ber_bvfree (bv=0x93f4fc0) at memory.c:369
369 LBER_FREE( bv->bv_val );
(gdb) print *bv
$1 = {bv_len = 2052, bv_val = 0x804 <Address 0x804 out of bounds>}
(gdb) up
#2 0x08098bc8 in ber_bvecfree (bv=0x94b3288) at memory.c:390
390 ber_bvfree( bv[i] );(gdb) where
And another (note the similar bad address?)
(gdb) where
#0 ad_free (ad=0x803, freeit=1) at ad.c:50
#1 0x0805399f in attr_free (a=0x8f39c60) at attr.c:32
#2 0x080539d0 in attrs_free (a=0x8f81368) at attr.c:44
#3 0x0805455a in entry_free (e=0x8cc2860) at entry.c:285
#4 0x0807706a in cache_add_entry_rw (cache=0x80ddaec, e=0x8bce600, rw=0)
at cache.c:353
#5 0x0807bde6 in id2entry_rw (be=0x80dd4a8, id=3511, rw=0) at id2entry.c:158
#6 0x08073682 in ldbm_back_search (be=0x80dd4a8, conn=0x402bfd78,
op=0x8fb5870, base=0x8ffd5e0 "dc=ne-worcs,dc=ac,dc=uk",
nbase=0x8fb2820 "DC=NE-WORCS,DC=AC,DC=UK", scope=2, deref=2, slimit=-1,
tlimit=-1, filter=0x90074a0,
filterstr=0x8fe81d8 "(&(objectClass=person)(uid=greenl))",
attrs=0x8ffe2d0, attrsonly=0) at search.c:205
#7 0x0805137f in do_search (conn=0x402bfd78, op=0x8fb5870) at search.c:278
#8 0x08050088 in connection_operation (arg_v=0x8f803e8) at connection.c:831
#9 0x08085378 in ldap_pvt_thread_pool_submit (pool=0x80baf98,
start_routine=0x804ff28 <connection_operation>, arg=0x8f803e8)
at thr_stub.c:159
#10 0x08050ae5 in connection_op_activate (conn=0x402bfd78, op=0x8fb5870)
at connection.c:1234
#11 0x08050838 in connection_input (conn=0x402bfd78) at connection.c:1124
#12 0x080504b5 in connection_read (s=20) at connection.c:1019
#13 0x0804e79b in slapd_daemon_task (ptr=0x0) at daemon.c:1181
#14 0x080852cc in ldap_pvt_thread_create (thread=0xbffff8b0, detach=0,
start_routine=0x804d7c8 <slapd_daemon_task>, arg=0x0) at thr_stub.c:48
#15 0x0804e994 in slapd_daemon () at daemon.c:1247
#16 0x0804c35a in main (argc=3, argv=0xbffff96c) at main.c:443
#17 0x40197e5e in __libc_start_main (main=0x804bd20 <main>, argc=3,
ubp_av=0xbffff96c, init=0x804ae00 <_init>, fini=0x809c920 <_fini>,
rtld_fini=0x4000d3c4 <_dl_fini>, stack_end=0xbffff95c)
at ../sysdeps/generic/libc-start.c:129
(gdb) print *ad
Cannot access memory at address 0x803
(gdb) up
(gdb) print *a
$1 = {a_desc = 0x803, a_vals = 0x8d96370, a_next = 0x9077830}
(gdb) print *a_vals
No symbol "a_vals" in current context.
(gdb) pring *a->a_vals
Undefined command: "pring". Try "help".
(gdb) print *a->a_vals
$2 = (struct berval *) 0x907cb88
(gdb) print **a->a_vals
$3 = {bv_len = 8, bv_val = 0x907cb98 "payc1046"}
(gdb) print *a->a_next
$4 = {a_desc = 0x8f875c0, a_vals = 0x8fc1f08, a_next = 0x9028c60}
(gdb) print *a->a_next->a_vals
$5 = (struct berval *) 0x8fc1f18
(gdb) print **a->a_next->a_vals
$6 = {bv_len = 8, bv_val = 0x8fc1f28 "students"}
(gdb) print *a->a_desc
Cannot access memory at address 0x803
(gdb) print *a->a_next
$7 = {a_desc = 0x8f875c0, a_vals = 0x8fc1f08, a_next = 0x9028c60}
(gdb) print *a->a_next->a_desc
$8 = {ad_cname = 0x90754d8, ad_type = 0x80db8b0, ad_lang = 0x0, ad_flags = 0}
(gdb) print *a->a_next->a_desc->ad_cname
$9 = {bv_len = 3, bv_val = 0x8f875d8 "gid"}
We have a large client site limping along due to this kind of problem (we saw
something similar with 2.0.7 and hoped the update would fix things) so any
help would be welcome.
The LDAP client is written in Perl using Net::LDAP (perl-ldap-0.23).
The URL I quoted below will give you the LDIF, our slapd.conf and schemas.
We are running on Red Hat 7.1