Bug 17199 - ElementRareDataMap should use OwnPtr to avoid any possible leaks
Summary: ElementRareDataMap should use OwnPtr to avoid any possible leaks
Status: RESOLVED INVALID
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: 528+ (Nightly build)
Hardware: Macintosh OS X 10.5
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-02-06 13:34 PST by Eric Seidel (no email)
Modified: 2014-01-13 21:56 PST (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Eric Seidel (no email) 2008-02-06 13:34:58 PST
ElementRareDataMap should use OwnPtr to avoid any possible leaks

Assuming this is safe,
typedef HashMap<const Element*, ElementRareData*> ElementRareDataMap;

Should be changed to:
typedef HashMap<const Element*, OwnPtr<ElementRareData>> ElementRareDataMap;

To avoid any possible leaks.  Holding new'd objects in raw pointers is dangerous.
Comment 1 Adam Roben (:aroben) 2008-02-06 13:42:58 PST
(In reply to comment #0)
> ElementRareDataMap should use OwnPtr to avoid any possible leaks
> 
> Assuming this is safe,
> typedef HashMap<const Element*, ElementRareData*> ElementRareDataMap;
> 
> Should be changed to:
> typedef HashMap<const Element*, OwnPtr<ElementRareData>> ElementRareDataMap;

I'm not sure this is possible, since OwnPtr isn't copyable.
Comment 2 Eric Seidel (no email) 2008-02-06 14:07:38 PST
Yeah, I tried.  OwnPtr isn't copyable, thus this didn't work.  There has to be a solution here though.  Maybe auto_ptr?  There should be construct we can use to do this safely, and make it *very obvious* when reading the code that the memory management is correct.
Comment 3 Anders Carlsson 2014-01-13 21:56:59 PST
We no longer store rare data in a side table.