CFTree: retain children and the context info - #51
Merged
Conversation
CFTree never took real ownership of anything:
* CFTreeAppendChild()/CFTreeInsertSibling() called the child's *context*
retain callback (passing the tree node, and a no-op for the default
NULL context) instead of retaining the child, and CFTreePrependChild()
retained nothing at all. A parent therefore did not keep its children
alive; releasing a child before its parent left the parent with a
dangling pointer (use-after-free when the tree was later traversed or
finalized).
* The context retain/release callbacks are meant to apply to the info
pointer, but CFTreeCreate() never retained the info and CFTreeFinalize()
passed the tree (not the info) to the release callback.
* CFTreeFinalize()/CFTreeRemoveAllChildren() called CFTreeFinalize()
directly on each child rather than releasing it, bypassing the normal
reference count.
Retain children with CFRetain() when they are added and release them with
CFRelease() in CFTreeRemove(), CFTreeRemoveAllChildren() and
CFTreeFinalize(); retain the info in CFTreeCreate() and release it (the
info, not the node) in CFTreeFinalize(); and fix CFTreePrependChild() to
set _lastChild to the new child and CFTreeGetChildAtIndex() to stop at the
end of the child list. Adds regression tests (verified leak- and
use-after-free-free under AddressSanitizer).
Builds on the CFTreeRemove() unlink fix; supersedes the smaller CFTree
null-dereference and CFTreeRemove changes.
…odel # Conflicts: # ChangeLog # Tests/CFTree/basic.m
fredkiefer
approved these changes
Aug 16, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
CFTree never took real ownership of anything:
CFTreeAppendChild()/CFTreeInsertSibling()called the child's context retain callback (passing the tree node, and a no-op for the default NULL context) instead of retaining the child, andCFTreePrependChild()retained nothing at all. A parent therefore did not keep its children alive; releasing a child before its parent left the parent with a dangling pointer (use-after-free when the tree was later traversed or finalized).The context retain/release callbacks are meant to apply to the
infopointer, butCFTreeCreate()never retained the info andCFTreeFinalize()passed the tree (not the info) to the release callback.CFTreeFinalize()/CFTreeRemoveAllChildren()calledCFTreeFinalize()directly on each child rather than releasing it, bypassing the normal reference count.This retains children with
CFRetain()when they are added and releases them withCFRelease()inCFTreeRemove(),CFTreeRemoveAllChildren()andCFTreeFinalize(); retains the info inCFTreeCreate()and releases the info (not the node) inCFTreeFinalize(); and fixesCFTreePrependChild()(set_lastChildto the new child) andCFTreeGetChildAtIndex()(stop at the end of the list). Regression tests added; verified leak-free and use-after-free-free under AddressSanitizer.Note: this is a comprehensive CFTree memory-management fix. It is stacked on the
CFTreeRemove()unlink fix, so the diff currently also includes that commit, and it supersedes the two smaller CFTree PRs (theCFTreePrependChild/CFTreeGetChildAtIndexnull-dereference fixes and theCFTreeRemoveunlink fix) — they can be closed in favour of this one, or this can be merged after them.