Description of problem:
ns-slapd is occasionally crashing while using schema-reload.pl. Crashes seems to be more frequent when there is more data/more schema files/more load in the system. Copy paste from /var/log/messages:
Mar 11 11:03:21 sprintlab070vm1 kernel: ns-slapd[62980]: segfault at bc ip 0000003be1cabfd4 sp 00007fc522bfa400 error 4 in libslapd.so.0.0.0[3be1c00000+f6000] Mar 11 12:11:03 sprintlab070vm1 kernel: ns-slapd[52594] general protection ip:3be1cabfd4 sp:7f3b0f5f6ba0 error:0 in libslapd.so.0.0.0[3be1c00000+f6000] Mar 11 12:26:49 sprintlab070vm1 kernel: ns-slapd[53038] general protection ip:3be1cabfd4 sp:7f78e1660460 error:0 in libslapd.so.0.0.0[3be1c00000+f6000]
Version-Release number of selected component (if applicable):
389-ds-base-1.2.11.15-12.el6_4.x86_64
How reproducible:
Occasionally
Steps to Reproduce: 1. Run the following script:
DM="cn=manager" DM_PASSWD="Manager" INSTANCE="myinstancee"
while true do echo "triggering schema reload" entry=/usr/lib64/dirsrv/slapd-${INSTANCE}/schema-reload.pl -D "${DM}" -w ${DM_PASSWD} |grep "adding new entry"|cut -c 18-|sed s/\"//g
/usr/lib64/dirsrv/slapd-${INSTANCE}/schema-reload.pl -D "${DM}" -w ${DM_PASSWD} |grep "adding new entry"|cut -c 18-|sed s/\"//g
echo "reload triggered, task entry: ${entry}" while true do e=/usr/lib64/mozldap/ldapsearch -1 -D "${DM}" -w ${DM_PASSWD} -b "${entry}" "(objectclass=*)" nstaskstatus ec=$? if echo $e|grep "Schema reload task finished" then break fi
/usr/lib64/mozldap/ldapsearch -1 -D "${DM}" -w ${DM_PASSWD} -b "${entry}" "(objectclass=*)" nstaskstatus
echo "$ec waiting for task ${entry} to finish." if [ "$ec" -ne "0" ] then exit fi sleep 1
done echo "schema reloaded" echo "" done
Actual results: ns-slapd throws segfault from time to time
Expected results: no segfault should happen
Additional info:
Attached abrt outcome of one crash. backtrace follows:
key=0x7fa7b6bfa4b0) at ldap/servers/slapd/slapd_plhash.c:73
key=0x7fa7b6bfa4b0) at ldap/servers/slapd/slapd_plhash.c:91
(name=0x7fa7b6bfa4b0 "cn", use_lock=1) at ldap/servers/slapd/attrsyntax.c:321
type=0x7fa770317df0 "cn", use_lock=1) at ldap/servers/slapd/attr.c:252
ldap/servers/slapd/attr.c:328
ldap/servers/slapd/entry.c:2107
arg=0x7fa7b6bfa970 "\360$") at ldap/servers/slapd/dse.c:1087
fn=0x7fa7d47ee4e0 , arg=0x7fa7b6bfa970 "\360$", stopflag=-2) at ldap/libraries/libavl/avl.c:514
fn=0x7fa7d47ee4e0 , arg=0x7fa7b6bfa970 "\360$", stopflag=-2) at ldap/libraries/libavl/avl.c:510
ldap/servers/slapd/dse.c:1023
ldap/servers/slapd/dse.c:1462
ldap/servers/slapd/delete.c:364
ldap/servers/slapd/delete.c:242
out>) at ldap/servers/slapd/task.c:636
ldap/servers/slapd/eventq.c:312
../../../mozilla/nsprpub/pr/src/pthreads/ptthread.c:167
pthread_create.c:301
../sysdeps/unix/syscall-template.S:82
git patch file (master) 0001-Ticket-627-ns-slapd-crashes-sporadically-with-segmen.patch
Bug Description: Schema reload task (schema-reload.pl) was not thread safe.
Fix Description: Attribute Syntax is stored in the hash and retrieved based upon the attribute syntax. When Schema reload task is invoked, the attribute syntax objects were completely replaced ignoring the lock protection. This patch protects the attribute syntax replacement (attr_syntax_delete_all_for_ schemareload) with the write lock. Also, attribute syntax object maintains the reference count. The schema reload respects the reference count instead of blindly deleting them.
Reviewed by Rich (Thank you!!)
Pushed to master: commit 81b997480956b2b6fa3a5d0e8d6abf5113a06400 Pushed to 389-ds-base-1.3.0 branch: commit a7ae8de6e50ae209737f8927cf3a63e875620911 Pushed to 389-ds-base-1.2.11 branch: commit c82987275bec0e1eb1a6c9b853fcaf389a300e71
Metadata Update from @nhosoi: - Issue assigned to nhosoi - Issue set to the milestone: 1.2.11.20
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/627
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: Fixed)