skip to content

Why is it unsafe to release an owning handle to an object before the last read of that object's fields?

level: seniorimportance: should knowfreq 44%

answer

  1. destruction is synchronous with the decrement
  2. an inner pointer carries no count
  3. last mention is not last use
  4. keep an owner alive across the use
  5. cleanup reads fields before they are released

basics

~20 s

Releasing may take the count to zero, which destroys the object immediately. Any pointer still aimed at the object or inside it — an interior pointer, a borrowed field address, a buffer handed to someone else — becomes a dangling pointer at that instant, and the next read is a use-after-free.

solid answer

~50 s

Destruction in a counted system is synchronous with the decrement, so the ordering of the release against the last use is a correctness question, not a style question. The dangerous pattern is taking a pointer *into* an object — the address of a field, an inner buffer, an element — and then dropping the owning handle while that pointer is still live. If that release is the last one, the object is torn down and its memory returned before the pointer is used. It appears in three guises: an interior pointer that outlives its owner, an expression that borrows through a temporary whose owner is cleared mid-way, and an optimiser that ends a handle's lifetime at its last *syntactic* mention rather than at the last use of anything derived from it. The fixes are to hold an owning handle across the whole use, to copy the value out instead of borrowing a pointer, or to use an explicit keep-alive marker where the language provides one.

code

pseudocode · 10 lines
pseudocode
// hazard: the last owner dies while p still points inside the object
p = address_of(obj.buffer)
release(obj)            // count hits 0 here: cleanup runs, memory freed
write(p, 42)            // p now points into freed memory

// safe: an owning handle covers the whole use
keep = obj              // increment: a second owner exists
p = address_of(keep.buffer)
write(p, 42)            // object is provably alive here
release(keep)           // decrement only after the last use

go deeper

for a junior

Remember that a plain pointer into an object is not an owner. If the real owner is released, the object can be destroyed while that pointer still exists.

for a middle

Explain that destruction happens synchronously at the decrement, and show the pattern: take an inner pointer, release the owner, then use the pointer.

for a senior

Recognise the production signature — fine in tests, corruption far from the site, different behaviour in optimised builds — and give the fix as an owning handle that spans the whole use.

for a principal

Treat it as an interface rule: decide whether your APIs may hand out interior pointers at all, and what the codebase's convention is for keep-alive markers where lifetimes can be shortened.

## Why ordering is a correctness property here In a counted system, a decrement that reaches zero destroys the object *there*, synchronously, before the next statement runs. That makes the position of a release relative to the last use of the object a hard correctness constraint. In a traced system the same code is usually harmless, because an object stays alive as long as anything can still reach it and the collector is the one deciding when to act. Counting has no such safety net: the release is the decision, and the only thing standing between the program and a use-after-free is that some owning handle is still alive at the moment of the read. The invariant to state plainly: **an owning handle must remain alive at least until the last read or write of anything derived from that object.** ## Three shapes of the bug 1. **The interior pointer.** Code takes the address of a field or of a buffer inside the object, releases the owning handle, and then uses that address. The pointer is not a handle and carries no count, so nothing about it keeps the object alive. This is the single most common form, because handing out an inner pointer is such a natural way to avoid copying. 2. **The borrowed temporary.** An expression obtains a non-owning view through one call and, in the same expression or shortly after, causes the owner to be cleared, replaced or resized. A container that owned the only handle is emptied, the element's count reaches zero, and the view that was still being read points into freed memory. The lifetime bug is hidden inside what looks like one atomic-looking line of code. 3. **Lifetime shortened at the last mention.** An implementation is free to end a handle's lifetime as soon as the variable is never mentioned again, rather than at the end of the enclosing block. If the remaining work uses something *derived* from the object — an inner pointer, a resource whose validity the object owns — the release can be moved before that work. This is why systems that shorten lifetimes provide an explicit keep-alive marker: a construct that consumes the handle at a chosen program point purely to forbid the release from floating above it. A fourth, inside the implementation itself, is the same hazard one level down: when an object reaches zero, its own cleanup must run *before* its fields' handles are released, because the cleanup typically reads those fields. Releasing fields first destroys the things the cleanup is about to use. ## Symptoms and why they are hard to see | what you observe | why counting makes it look like this | |---|---| | works in testing, fails under load | the object often has a second owner in simple tests, so the release does not reach zero | | corruption far from the release | the freed block is reused by an unrelated allocation before the stale read happens | | disappears when logging is added | the extra code keeps a handle alive or changes allocation reuse timing | | fails only in optimised builds | lifetime shortening applies only when the optimiser is allowed to move the release | The deeper reason these are hard is that the count itself makes the bug conditional: the identical code is correct whenever any other owner happens to exist, and fatal only on the path where this handle was the last one. ## How to write it so it cannot happen - **Bind an owning handle for the whole use.** Acquire a handle into a local, take the inner pointer from that local, finish all the work, and let the local die afterwards. The extra increment is cheap compared with the failure mode. - **Copy out rather than borrow.** If what is needed is a value, take the value; a copy has no lifetime dependency on the object at all. - **Do not return inner pointers across an ownership boundary.** An interface that hands out an address into an object it owns is asking every caller to reason about the owner's lifetime correctly. - **Use the keep-alive construct where lifetimes may be shortened.** Place it after the last use of anything derived from the object, so the release provably cannot move above it. - **Release fields after cleanup inside the destructor.** State the order explicitly, because getting it backwards produces exactly the same bug in code that everyone trusts. The interview answer worth giving is that the count is not a suggestion: it is the exact mechanism that decides when memory goes away, so any code that holds a raw pointer into a counted object is quietly asserting something about ownership, and the assertion has to be made real by keeping a handle alive.

  • Why is the same pattern usually harmless in a runtime that reclaims by tracing instead of counting?
    Because reclamation there is not triggered by an individual release. An object survives while anything can still reach it, and the collector decides when to act, so ending a handle's life early normally has no immediate effect. The analogous bug still exists when a pointer escapes into memory the collector does not scan, which is why such runtimes also provide a way to say explicitly that an object must be treated as live up to a given point.
  • How does an optimiser that shortens a handle's lifetime turn correct-looking code into a use-after-free?
    It may end the handle's life at the last mention of the variable rather than at the end of the block. If the code after that point uses something derived from the object — an interior pointer, a resource the object owns — the release has been moved before that use, and it may be the one that reaches zero. A keep-alive construct placed after the last derived use is what forbids the move.
  • Inside a destructor, why must the object's own cleanup run before its fields' handles are released?
    Because cleanup usually reads those fields — flushing a buffer, closing something the field describes, unregistering with an object it points at. Releasing the fields first can take each of their counts to zero, destroying them, so the cleanup then reads freed memory. It is the same ordering hazard as the caller-side one, committed inside the reclamation routine, and it is why release routines specify the order rather than leaving it to taste.

saying these in an interview costs you the question

  • Thinks a raw pointer into an object keeps that object alive
  • Believes destruction is deferred, so ordering cannot matter
  • Assumes a handle always lives until the end of its block
  • Releases an object's fields before running its cleanup
  • Calls it a rare race rather than a deterministic ordering bug
  • Says testing would have caught it, ignoring the second-owner case