Bug 123763 - FrameView destructor is worried about being retained by a renderer.
Summary: FrameView destructor is worried about being retained by a renderer.
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Andreas Kling
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-11-04 16:21 PST by Andreas Kling
Modified: 2013-11-04 17:38 PST (History)
3 users (show)

See Also:


Attachments
Patch (1.31 KB, patch)
2013-11-04 16:22 PST, Andreas Kling
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Andreas Kling 2013-11-04 16:21:37 PST
// FIXME: How could this ever happen when RenderWidget retains the Widget!?

Indeed.
Comment 1 Andreas Kling 2013-11-04 16:22:04 PST
Created attachment 215965 [details]
Patch
Comment 2 Darin Adler 2013-11-04 17:21:54 PST
Comment on attachment 215965 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=215965&action=review

> Source/WebCore/ChangeLog:8
> +        There's no way we can be in ~FrameView() while also being owned by
> +        a RenderWidget. Remove some overly paranoid code that was making sure
> +        the renderer didn't have a reference on us.

Could you have put in an assertion or is this so obviously true that an assertion would be a waste?
Comment 3 Andreas Kling 2013-11-04 17:23:26 PST
(In reply to comment #2)
> (From update of attachment 215965 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=215965&action=review
> 
> > Source/WebCore/ChangeLog:8
> > +        There's no way we can be in ~FrameView() while also being owned by
> > +        a RenderWidget. Remove some overly paranoid code that was making sure
> > +        the renderer didn't have a reference on us.
> 
> Could you have put in an assertion or is this so obviously true that an assertion would be a waste?

I thought about it, and it seemed to me that asserting in ~Foo() that someone's RefPtr<Foo> isn't pointing to |this| is overly paranoid. WDYT?
Comment 4 Darin Adler 2013-11-04 17:30:30 PST
(In reply to comment #3)
> I thought about it, and it seemed to me that asserting in ~Foo() that someone's RefPtr<Foo> isn't pointing to |this| is overly paranoid. WDYT?

Yes, and no. Paranoid, yes. But catching overrelease in the destructor might be great instead of having to debug use of the deallocated memory later. I wish every class could have a check like this one. If this would help us debug a case where we someone does an extra deref, then it would be great.

Not really sure how to judge.
Comment 5 WebKit Commit Bot 2013-11-04 17:31:39 PST
Comment on attachment 215965 [details]
Patch

Clearing flags on attachment: 215965

Committed r158625: <http://trac.webkit.org/changeset/158625>
Comment 6 WebKit Commit Bot 2013-11-04 17:31:40 PST
All reviewed patches have been landed.  Closing bug.
Comment 7 Andreas Kling 2013-11-04 17:33:28 PST
(In reply to comment #4)
> (In reply to comment #3)
> > I thought about it, and it seemed to me that asserting in ~Foo() that someone's RefPtr<Foo> isn't pointing to |this| is overly paranoid. WDYT?
> 
> Yes, and no. Paranoid, yes. But catching overrelease in the destructor might be great instead of having to debug use of the deallocated memory later. I wish every class could have a check like this one. If this would help us debug a case where we someone does an extra deref, then it would be great.

Doesn't RefCounted already do something like this with the deletion-has-begun assertions?
Comment 8 Darin Adler 2013-11-04 17:38:25 PST
(In reply to comment #7)
> Doesn't RefCounted already do something like this with the deletion-has-begun assertions?

Maybe it does!