Enabling Retro Changelog Plugin on a DS instance provisioned by Samba will crash slapd during startup. This problem can be reproduced consistently. Steps to Reproduce: 1. Run Samba provisioning tool to create DS instance. 2. Start DS instance. 3. Use ldapmodify to enable Retro Changelog Plugin. 4. Stop DS instance. 5. Start DS instance again. Actual results: DS will crash in step 5. Expected results: DS should not crash. Apparently the retrocl_internal_lock is still NULL when it's used in retrocl_get_first_changenumber(). The solution is to initialize the lock in the retrocl_plugin_init().
Created attachment 383319 [details] Patch
Created attachment 383322 [details] Removed duplicate external declaration.
commit 51fab34954121f128f5b2424fc2b6dfd34054193 Author: Endi S. Dewata <endisd> Date: Tue Jan 12 04:00:30 2010 -0600 pushed to master by rmeggins
can you please add steps to reproduce this fix with DS only? Thanks
As discussed in the mailing list, it seems that the crash happened in some parts of the change log plugin that tried to use the retrocl_internal_lock without checking for NULL pointer. The patch fixed the problem by initializing the lock during plugin initialization so now the lock can be used without checking for NULL pointer. It might be possible to verify the crash with these steps: 1. Create DS instance. 2. Configure changelog. 3. Restart the server. 4. Search root DSE for the firstchangenumber and lastchangenumber attributes. Step #4 will invoke these methods: - retrocl_get_first_changenumber() - retrocl_get_last_changenumber() which would have crashed had this problem not been fixed. Probably having been configured with Samba somehow the DS will invoke retrocl_get_first_changenumber() during startup which would trigger the original problem.
The problem can be reproduced by reverting the patch from the latest code and following the steps in the original bug description. The stack trace indicates that the cos plugin executes an internal root DSE search during startup which triggers the problem: #0 0x005c7bed in pthread_mutex_lock () from /lib/libpthread.so.0 #1 0x071e3c53 in PR_Lock (lock=0x0) at ../../../mozilla/nsprpub/pr/src/pthreads/ptsynch.c:206 #2 0x0045f44b in retrocl_get_first_changenumber () at ldap/servers/plugins/retrocl/retrocl_cn.c:270 #3 0x00461189 in retrocl_rootdse_search (pb=0xb3800fc8, e=0xb3802ba8, entryAfter=0x0, returncode=0xb43f9440, returntext=0xb43f965c "", arg=0x0) at ldap/servers/plugins/retrocl/retrocl_rootdse.c:84 #4 0x002bc4d0 in dse_call_callback (pdse=<value optimized out>, pb=0xb3800fc8, operation=4, flags=1, entryBefore=0xb3802ba8, entryAfter=0x0, returncode=0xb43f9440, returntext=0xb43f965c "") at ldap/servers/slapd/dse.c:2232 #5 0x002be364 in dse_search (pb=0xb3800fc8) at ldap/servers/slapd/dse.c:1710 #6 0x002f1e4d in op_shared_search (pb=0xb3800fc8, send_result=1) at ldap/servers/slapd/opshared.c:638 #7 0x002fcc57 in search_internal_callback_pb (pb=0xb3800fc8, callback_data=<value optimized out>, prc=0x2fc790 <internal_plugin_result_callback>, psec=0x2fd150 <internal_plugin_search_entry_callback>, prec=0x2fd0e0 <internal_plugin_search_referral_callback>) at ldap/servers/slapd/plugin_internal_op.c:761 #8 0x002fceed in search_internal_pb (pb=0xb3800fc8) at ldap/servers/slapd/plugin_internal_op.c:611 #9 0x002fdbf1 in slapi_search_internal (base=0xe781b5 "", scope=0, filter=0xe784f2 "(objectclass=*)", controls=0x0, attrs=0xb43fe280, attrsonly=0) at ldap/servers/slapd/plugin_internal_op.c:455 #10 0x00e7641c in cos_cache_build_definition_list () at ldap/servers/plugins/cos/cos_cache.c:678 #11 cos_cache_create () at ldap/servers/plugins/cos/cos_cache.c:529 #12 0x00e77d49 in cos_cache_wait_on_change (arg=0x0) at ldap/servers/plugins/cos/cos_cache.c:493 #13 0x071ea032 in _pt_root (arg=0x84340c8) at ../../../mozilla/nsprpub/pr/src/pthreads/ptthread.c:228 #14 0x005c5ab5 in start_thread () from /lib/libpthread.so.0 #15 0x00747dae in clone () from /lib/libc.so.6 If the patch is applied back, the problem no longer appears.