Bug 16033
| Summary: | REGRESSION(r27022): testapi exits with assertion failure in debug build: ASSERTION FAILED: s <= HeapConstants<heapType>::cellSize | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Mark Rowe (bdash) <mrowe> |
| Component: | JavaScriptCore | Assignee: | Mark Rowe (bdash) <mrowe> |
| Status: | RESOLVED FIXED | ||
| Severity: | Normal | Keywords: | HasReduction, InRadar, Regression |
| Priority: | P1 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | Mac | ||
| OS: | OS X 10.5 | ||
Mark Rowe (bdash)
ASSERTION FAILED: s <= HeapConstants<heapType>::cellSize
(/Volumes/Data/Home/Documents/Work/WebKit-git/OpenSource/JavaScriptCore/kjs/collector.cpp:202 static void* KJS::Collector::heapAllocate(size_t) [with KJS::Collector::HeapType heapType = PrimaryHeap])
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0xbbadbeef
#0 0x002f3403 in KJS::Collector::heapAllocate<(KJS::Collector::HeapType)0> (s=36) at collector.cpp:202
#1 0x00299339 in KJS::Collector::allocate (s=36) at collector.cpp:306
#2 0x0029934d in KJS::JSCell::operator new (size=36) at value.cpp:39
#3 0x002fc922 in JSGlobalContextCreate (globalObjectClass=0x507b10) at /Volumes/Data/Home/Documents/Work/WebKit-git/OpenSource/JavaScriptCore/API/JSContextRef.cpp:48
#4 0x0000340b in main (argc=1, argv=0xbffff72c) at /Volumes/Data/Home/Documents/Work/WebKit-git/OpenSource/JavaScriptCore/API/testapi.c:501
The allocation in question is:
globalObject = new JSCallbackObject<JSGlobalObject>(0, globalObjectClass, jsNull(), 0);
which is apparently now 36 bytes in size, 4 bytes larger than the maximum cell size of 32 bytes.
This is simple to reproduce. Simply run testapi without any arguments.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Mark Rowe (bdash)
The fix to this is probably going to be to remove the m_isInitialized member of JSCallbackObject. Geoff mentioned the following in the patch review that added that member:
> A solution to this problem that would avoid the awkwardness of double initializaiton,
> fix <rdar://problem/5440659>, and avoid taking the precious last 4 bytes away from
> JSCallbackObject would be to refactor Interpreter so that construction and global
> object initialization were two separate steps (i.e., remove the JSObject* parameter to
> Interpreter::Interpreter()).
>
> That way, you could make an interpreter, use it to construct the global object, and
> then assign the global object to the interpreter.
Mark Rowe (bdash)
<rdar://problem/5607032>
Mark Rowe (bdash)
Fixed with r27885.