Segfault on SyncRepl activation

[389-ds-bot]

Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/48292

• Created at 2015-09-24 14:50:48 by canepan
• Closed as Duplicate
• Assigned to nobody

---

Hello, I'm trying to setup a partial replica of the LDAP tree stored in 389-ds by FreeIPA 4.1 (under CentOS 7), so that legacy systems have a local copy of the data needed to authenticate.
Those systems have already OpenLDAP installed, so I 'm trying to enable syncrepl from DS to OL.
I followed this ticket: https://fedorahosted.org/freeipa/ticket/3967 and I enabled the 2 plugins as indicated.
When the slave starts and tries to sync, the ns-slapd process on FreeIPA server dies, with this in syslog:

kernel: ns-slapd[4801]: segfault at 0 ip 00007f0f041f2db6 sp 00007f0ecc7f0f38 error 4 in libc-2.17.so[7f0f0416e000+1b6000]
immediately (same second) followed by:
named[1974]: LDAP error: Can't contact LDAP server: ldap_sync_poll() failed
named[1974]: ldap_syncrepl will reconnect in 60 seconds
systemd: dirsrv@XXX.service: main process exited, code=killed, status=11/SEGV

There is nothing in access or error log (found in /var/log/dirsrv/INSTANCE) at that second (last log is 30 seconds before the problem).

Even if replica doesn't work, I think it shouldn't kill the daemon.

The ldif used on the slave:

dn: olcDatabase={1}bdb,cn=config
changetype: modify
replace:olcSyncrepl
olcSyncrepl: rid=0001
provider=ldap://AAA.TLD
type=refreshOnly
interval=00:1:00:00
retry="5 5 300 +"
searchbase="YYY"
attrs="*,+"
bindmethod=simple
binddn="uid=XXX,cn=users,cn=accounts,dc=YYY"
credentials=ZZZ

[389-ds-bot]

Comment from canepan at 2015-09-24 15:00:38

gdb-generated trace
stacktrace.1443082692.txt

[389-ds-bot]

Comment from lkrispen (@elkris) at 2015-09-24 20:39:22

what is the exact DS verion: rpm -q 389-ds-base

thanks for the stack. unfortunately it was taken without debuginfo installed, could you repeat and do a bt full for the crashing thread ?

Or could you provide steps to reproduce ?

[389-ds-bot]

Comment from lkrispen (@elkris) at 2015-09-28 14:05:33

the stack trace of the crash is identical to that in bz 952036 / ticket 47939 and this is fixed in ds389 1.3.3, so please provide version info.
If it is in a version which contains the mentioned fix, we need stacktrace with debuginfo and/or steps to reproduce

[389-ds-bot]

Comment from nhosoi (@nhosoi) at 2015-09-28 22:07:20

Thanks to Ludwig for investigating the core.

canepan, please provide the version info of 389-ds-base:
rpm -q 389-ds-base

If it is newer than 389-ds-base-1.3.3.7 or 389-ds-base-1.3.3.1-8, please provide the requests in https://fedorahosted.org/389/ticket/48292#comment:2. Thanks.

[389-ds-bot]

Comment from nhosoi (@nhosoi) at 2015-10-22 22:37:39

Although we have not received a response to the question in #comment:3, the stacktraces look very similar to the ticket 47939, which was fixed in 389-ds-base-1.3.3.7 or 389-ds-base-1.3.3.1-8 and newer.

Closing this ticket as dup of 47939. Please feel free to reopen this ticket if you still have the symptom with the newer version.

[389-ds-bot]

Comment from nhosoi (@nhosoi) at 2017-02-11 23:07:41

Metadata Update from @nhosoi:

• Issue set to the milestone: N/A