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.
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.
<rdar://problem/5607032>
Fixed with r27885.