[Webkit-unassigned] [Bug 69942] When an API test fails, TestWebKitAPI crashes

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Dec 21 09:46:35 PST 2011


https://bugs.webkit.org/show_bug.cgi?id=69942





--- Comment #14 from David Kilzer (ddkilzer) <ddkilzer at webkit.org>  2011-12-21 09:46:34 PST ---
(In reply to comment #12)
> (In reply to comment #11)
> > (In reply to comment #10)
> > > I guess I should work on reintroducing the changes I did related to bug 66521
> > 
> > I have a potential fix for the Mac.  Will post a patch shortly.
> 
> Well, I thought I had a fix.
> 
> What I thought I was seeing in release builds is that FastMalloc.h was redefining the 'new' and 'delete' operators to use fastMalloc() and fastFree() when ENABLE(GLOBAL_FASTMALLOC_NEW) was true.
> 
> This caused any use of 'new' and 'delete' in gtest headers to start using fastMalloc() and fastFree(), which contracted the use of malloc() and free() in gtest source code, so you ended up with crashes like the one in this bug.
> 
> My initial solution was to do this in TestWebKitAPI/config.h (thereby turning off the redefining of 'new' and 'delete'):
> 
> +#define ENABLE_GLOBAL_FASTMALLOC_NEW 0
>  #include <wtf/Platform.h>
> 
> This change fixed crashes in Release builds when a WTF::String() comparison fails (and when compiling with "-g -O0"), but I'm still seeing crashes on Debug builds.  Investigating.

Of course, the problem with this approach is that 'new' and 'delete' operators in JavaScriptCore headers now will NOT be redefined as fastMalloc() and fastFree(), so there will be mismatches when creating/deleting JSC objects.

-- 
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