wiki:detect a RenderObject is destroyed unsafely

Version 5 (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

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.

Actionable things

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