Bug 17199
| Summary: | ElementRareDataMap should use OwnPtr to avoid any possible leaks | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Eric Seidel (no email) <eric> |
| Component: | New Bugs | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED INVALID | ||
| Severity: | Normal | CC: | andersca, aroben, mjs |
| Priority: | P2 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | Mac | ||
| OS: | OS X 10.5 | ||
Eric Seidel (no email)
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.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Adam Roben (:aroben)
(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.
Eric Seidel (no email)
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.
Anders Carlsson
We no longer store rare data in a side table.