[Webkit-unassigned] [Bug 28726] New: Valgrind mismatched malloc/delete @ CSSSelectorList::adoptSelectorVector()
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Tue Aug 25 17:27:18 PDT 2009
https://bugs.webkit.org/show_bug.cgi?id=28726
Summary: Valgrind mismatched malloc/delete @
CSSSelectorList::adoptSelectorVector()
Product: WebKit
Version: 528+ (Nightly build)
Platform: Macintosh
OS/Version: Mac OS X 10.5
Status: NEW
Keywords: InChromiumBugs, Regression
Severity: Normal
Priority: P2
Component: Web Template Framework
AssignedTo: webkit-unassigned at lists.webkit.org
ReportedBy: playmobil at google.com
CC: mark at chromium.org, darin at apple.com,
playmobil at google.com, deanm at chromium.org
Chromium bug: http://crbug.com/18984
https://bugs.webkit.org/show_bug.cgi?id=22834 (checked in as r41877) fixed a
mismatched new/free Valgrind warning.
This has now reappeared as the opposite - a mismatched malloc/delete.
The problem is that the patch for the bug above changed
- fastFree(selectorVector[i])
+ // We want to free the memory (which was allocated with new), but we
+ // don't want the destructor to run since it will affect the copy
+ // we've just made. In theory this is undefined, but operator delete
+ // is only defined taking a void*, so in practice it should be ok.
+ delete reinterpret_cast<char*>(selectorVector[i]);
It appears things have moved around and the original allocation's use of
operator new now calls through to FastAllocBase which calls malloc().
The bizarre part is that the delete hack used above seems to bypass
FastAllocBase's operator delete (which calls free) and instead call the system
library version instead, thus triggering a Valgrind warning.
We probably need to revert this part of the aforementioned patch or come up
with a better long-term solution.
--
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
More information about the webkit-unassigned
mailing list