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

Re: (ITS#3989) syncprov core dumps when combined with uniqueness overlay



The backtraces attached here are incomplete. Note that even though you 
specified "thread apply all" in the backtrace command, gdb stopped 
tracing after thread 3 because gdb thought that thread's stack trace was 
corrupted. You have to manually issue backtrace commands for threads 2 
and 1 in this case in order to get a complete picture of what's going 
on. (Really I believe gdb is just being stupid here and not able to 
detect that it reached the top of thread 3's stack; there obviously 
cannot be anything beyond lwp_start. Perhaps a newer gdb would recognize 
it.)

quanah@stanford.edu wrote:
> gdb says:
>
> #0  0x000d8c08 in syncprov_op_abandon (op=0x5e3ff540, rs=0x5e3ff4a8) at
> syncprov.c:947
> 947     syncprov.c: No such file or directory.
>         in syncprov.c
> (gdb) thr apply all bt
>
> Thread 4 (process 68118    ):
> #0  0xfee1f340 in _lwp_wait () from /usr/lib/libc.so.1
> #1  0xfed5d7b8 in lwp_wait () from /usr/lib/lwp/libthread.so.1
> #2  0xfed590a0 in _thrp_join () from /usr/lib/lwp/libthread.so.1
> #3  0x000245dc in slapd_daemon () at daemon.c:2045
> #4  0x00016a18 in main ()
>
> Thread 3 (process 330262    ):
> #0  0x000a0460 in bdb_entry_get (op=0xb5d3a8, ndn=0x5d3fdaf0, oc=0x1b18e0,
> at=0x15ac00, rw=0, ent=0x5d3fd56c) at id2entry.c:386
> #1  0x00032024 in be_entry_get_rw (op=0x0, ndn=0x5d3fdaf0, oc=0x1b18e0,
> at=0x15ac00, rw=0, e=0x5d3fd56c) at backend.c:1194
> #2  0x000320c4 in fe_acl_group (op=0xb5d3a8, target=0x5d3ff470,
> gr_ndn=0x5d3fdaf0, op_ndn=0xb5d440, group_oc=0x1b18e0, group_at=0x1d6db8) at
> backend.c:1239
> #3  0x000325a0 in backend_group (op=0xb5d3a8, target=0x5d3ff470,
> gr_ndn=0x5d3fdaf0, op_ndn=0xb5d440, group_oc=0x1b18e0, group_at=0x1d6db8) at
> backend.c:1390
> #4  0x0004497c in slap_acl_mask (a=0x1d58e8, mask=0x5d3fdfb4, op=0xb5d3a8,
> e=0x5d3ff470, desc=0x1d85d0, val=0x1886008, nmatch=100, matches=0x5d3fdfb8,
>     count=3, state=0x5d3fe9a8) at acl.c:1845
> #5  0x00042c50 in access_allowed_mask (op=0xb5d3a8, e=0x5d3ff470, desc=0x225220,
> val=0x1886008, access=ACL_WADD, state=0x5d3fe9a8, maskp=0x0) at acl.c:732
> #6  0x00045ab8 in acl_check_modlist (op=0xb5d3a8, e=0x5d3ff470, mlist=0x1530b60)
> at acl.c:2350
> #7  0x00076ad8 in bdb_modify_internal (op=0xb5d3a8, tid=0x16174c0,
> modlist=0x1530b60, e=0x5d3ff470, text=0x5d3ffd6c, textbuf=0x5d3ff4b0 "",
> textlen=256)
>     at modify.c:49
> #8  0x0007790c in bdb_modify (op=0xb5d3a8, rs=0x5d3ffd58) at modify.c:467
> #9  0x00070b30 in overlay_op_walk (op=0xb5d3a8, rs=0x5d3ffd58, which=32768,
> oi=0x151d54, on=0x8000) at backover.c:488
> #10 0x00070c24 in over_op_func (op=0xb5d3a8, rs=0x5d3ffd58, which=op_modify) at
> backover.c:540
> #11 0x0003a540 in fe_op_modify (op=0xb5d3a8, rs=0x5d3ffd58) at modify.c:417
> #12 0x00039d48 in do_modify (op=0xb5d3a8, rs=0x5d3ffd58) at modify.c:200
> #13 0x00026974 in connection_operation (ctx=0xf2800, arg_v=0xb5d3a8) at
> connection.c:1061
> #14 0xff31cd38 in ldap_int_thread_pool_wrapper (xpool=0x189018) at tpool.c:478
> #15 0xfed658c8 in _lwp_start () from /usr/lib/lwp/libthread.so.1
> #16 0xfed658c8 in _lwp_start () from /usr/lib/lwp/libthread.so.1
> Previous frame identical to this frame (corrupt stack?)
> 0x000d8c08      947     in syncprov.c
> (gdb) quit
>
>
>
>
>
>   


-- 
  -- Howard Chu
  Chief Architect, Symas Corp.  http://www.symas.com
  Director, Highland Sun        http://highlandsun.com/hyc
  OpenLDAP Core Team            http://www.openldap.org/project/