Why is inst->inst_ref_count == 0 when the instance is busy or in the process of being put offline or deleted?

Replying to [comment:2 rmeggins]:

Why is inst->inst_ref_count == 0 when the instance is busy or in the process of being put offline or deleted?

Sharp eyes! It was not escaped from you... I added "goto bail;" Even if slapi_counter_get_value(inst->inst_ref_count) was positive, the backend deletion was happening.
{{{
@@ -138,13 +138,20 @@ ldbm_instance_index_config_delete_callback(Slapi_PBlock pb, Slapi_Entry e, Sla
[...]
- if (slapi_counter_get_value(inst->inst_ref_count) > 0) {
+ if ((slapi_counter_get_value(inst->inst_ref_count) > 0) ||
+ is_instance_busy(inst) ||
+ / check if the backend is ON or not.
+ * If offline or being deleted, non SUCCESS is returned. /
+ (slapi_mapping_tree_select(pb, &be, &referral, returntext) != LDAP_SUCCESS)) {
*returncode = LDAP_UNAVAILABLE;
rc = SLAPI_DSE_CALLBACK_ERROR;
+ goto bail;
}
}}}

Is
{{{
+ is_instance_busy(inst) ||
+ / check if the backend is ON or not.
+ * If offline or being deleted, non SUCCESS is returned. /
+ (slapi_mapping_tree_select(pb, &be, &referral, returntext) != LDAP_SUCCESS)) {
}}}
this necessary to fix the bug? I think just the 'goto bail' will fix the bug.

If it is necessary to check both inst_ref_count and is_instance_busy, then I think we should fix our refcounting - that is, we should never decrement the refcount if the instance is busy.

You need to declare be and referral.

Do you need to free or release be and/or referral if they are active and returned by slapi_mapping_tree_select()?

Well, I was just conservative. We could remove "is_instance_busy(inst)" check.

Do you need to free or release be and/or referral if they are active and returned by slapi_mapping_tree_select()?

Ah, referral yes, be no need. I'm updating the patch.

git patch file (master)
0001-Ticket-48250-Slapd-crashes-reported-from-latest-buil.patch

Thanks for the comments and discussion, Rich. I've replaced the patch.

Reviewed by Rich (Thank you!!)

Pushed to master:
88e7242..01fea1f master -> master
commit 01fea1f89a680358245677f72a67e9ccf196f66d

Pushed to 389-ds-base-1.3.4:
a80fe15..7a4b0a7 389-ds-base-1.3.4 -> 389-ds-base-1.3.4
commit 7a4b0a705ec7376e704f6ae591beabf6c8f890af

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/1581

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.