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

Re: syncrepl consumer locks up (ITS#3263)

Thanks for the info. This level of detail is really helping in locating the
Looks like another interaction with the group ACL. It segfaulted while it
tried to read the group entry.
I can't tell how far bdb_entry_get proceeded before he died, though. Can you
locate wehre it faulted within bdb_entry_get ?
- Jong-Hyuk

> => dn: [21] cn=subschema
> => acl_get: [22] attr syncreplCookie
> access_allowed: no res from state (syncreplCookie)
> => acl_mask: access to entry "cn=syncrepl123,dc=rentec,dc=com", attr
> "syncreplCookie" requested
> => acl_mask: to all values by "cn=update,dc=rentec,dc=com", (=n)
> <= check a_dn_pat: self
> => bdb_entry_get: ndn: "cn=administrators,dc=rentec,dc=com"
> => bdb_entry_get: oc: "groupOfNames", at: "member"
> zsh: 7139 segmentation fault (core dumped)  /opt/ldap/libexec/slapd -d -1
> -f /opt/ldap/conf/slapd.conf -h
> Could it be that something's wrong with my access rules? I don't know what
> somehow it dies in there somewhere. The rules are exactly the same on
> provider and consumer.
> Following is the stacktrace from the core:
> (dbx) threads
>       t@1  a  l@1   ?()   LWP suspended in  __lwp_wait()
>       t@2  a  l@2   reg_thread()   sleep on 0x2740d8  in  __lwp_park()
>       t@3  a  l@3   ipc_manage_thr()   sleep on 0xff392b20  in
>       t@4  a  l@4   ?()   LWP suspended in  _libc_poll()
> o>    t@5  a  l@5   ?()   signal SIGSEGV in  bdb_entry_get()
> (dbx) where -v
> current thread: t@5
> =>[1] bdb_entry_get(0xf9bffb1c, 0xf9bfde10, 0x2b14f8, 0x207800, 0x2ae860,
> 0xf9bfd504), at 0xc0a00
>   [2] backend_group(0x0, 0x4cf3c0, 0xf9bfde10, 0xf9bffc1c, 0x2b14f8,
> 0x2cd730),at 0x55460
>   [3] 0x673bc(0x2c8af0, 0x28ab58, 0x2, 0x23a3f8, 0x0, 0x22), at 0x673bb
>   [4] access_allowed(0xf9bffb1c, 0x16, 0x23a3fc, 0x23a3f8, 0x3,
> at0x65158
>   [5] backend_attribute(0xf9bffb1c, 0x0, 0x4cf440, 0x27ddc8, 0xf9bffa84,
> at 0x559d8
>   [6] 0x8e95c(0xf9bffb1c, 0x28c590, 0x7b, 0x23bc00, 0x0, 0x3cb25c), at
>   [7] do_syncrepl(0x1a, 0x2ebcd0, 0x0, 0x1d9800, 0x273b38, 0x0), at
>   [8] 0xec3b0(0x26ebc0, 0xf9bffe20, 0x5, 0x283930, 0x28, 0x283938), at
> (dbx) where -v t@2