Skip to content

[9.16] Gracefully handle resending a node to prune_tree()

Commit 2df147cb made the prune_tree() function use send_to_prune_tree() for triggering pruning of deleted leaf nodes' parents. This enabled the following sequence of events to happen:

  1. Node A, which is a leaf node, is passed to send_to_prune_tree() and its pruning is queued.

  2. Node B is added to the RBTDB as a child of node A before the latter gets pruned.

  3. Node B, which is now a leaf node itself (and is likely to belong to a different node bucket than node A), is passed to send_to_prune_tree() and its pruning gets queued.

  4. Node B gets pruned. Its parent, node A, now becomes a leaf again and therefore the prune_tree() call that handled node B calls send_to_prune_tree() for node A.

  5. Since node A was already queued for pruning in step 1 (but not yet pruned), the INSIST(!ISC_LINK_LINKED(node, prunelink)); assertion fails for node A in send_to_prune_tree().

The above sequence of events is not a sign of pathological behavior. Replace the assertion check with a conditional early return from send_to_prune_tree().

Closes #4596 (closed)

Merge request reports