wiki:detect a RenderObject is destroyed unsafely

Version 2 (modified by Simon Fraser, 13 years ago) (diff)

--

Issue RenderObject lifetimes RO destroyed in Node::detach(), which is badly named.

Complications

anonymous containers continuations multicol stuff who else is pointing at you

float lists in lines continuations line boxes around inline replaced elements

Would like a WeakPtr system (but high memory cost)

Why do you use RefPtr

secondary use can hold a ref

Can we use OwnPtr?

just helps you not leak, and documents explicit ownership we don't use OwnPtrs because of RenderArenas are they still a useful opt? Need to measure

RO guard is like a debug-only RefPtr. Maybe that's how it should be implemented.

Two approaches

  1. Global "I'm holding a ref to some renderer, so don't destroy any". Addresses risk of being too specific
  2. Smart-pointer type object: RenderPtr.

(We look at some stack traces). We should protect against higher-level re-entrancy issues e.g. updating style/layout in painting.

Actionable things Rename the detach() method Assert isMainThread() in Document::updateStyleForAllDocuments()