On May 23, 2011, at 1:34 PM, Raphael Kubo da Costa wrote:
While working on the EFL port, I've noticed that sometimes a FrameLoader's DocumentLoader ends up being deleted too early (FrameLoader::setDocumentLoader causes the current DocumentLoader to be deref'ed and freed), in the sense that later on Document::explicitClose tries to access this DocumentLoader instance that has already been freed, causing a crash.
This looks like a basic design problem. The document has a pointer to the document loader, and keeps that pointer even after the document loader has been destroyed. That is a broken design. Also, there is a Document::setDocumentLoader function, but nobody ever calls it. What we need are some test cases showing problems caused by this mistake that we can use as regression tests; then we should fix it by making some better relationship between the Document and DocumentLoader that guarantees we won’t have a dangling pointer. Either reference counting to keep the object alive, or code to zero out the pointer at some point before the object is deleted. -- Darin