wiki:detect a RenderObject is destroyed unsafely

Version 7 (modified by Simon Fraser, 9 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.

How would we fix these?

make sure you're actually done before releasing the protector hard to avoid false positives (OK if the repaint is the last thing you're doing). The RenderPtr model has this issue.

Need to handle "zombie" renderers: need to avoid having this be a worse issue.

How to land: add the guards incrementally and fix the assertions as they are detected.

Talk about style updates and asking if things are editable. Calls from DOM require the correct answer (have to update style). Calls from other areas may be willing to avoid style updates but get the wrong answer.

Actionable things

Rename the detach() method Measure the cost of removing RenderArena