91622 2012-07-18 07:10:10 -0700 Launching the Dashboard causes a crash in JSGlobalData() 2012-07-18 21:20:58 -0700 1 1 1 Unclassified WebKit JavaScriptCore 528+ (Nightly build) Mac (PowerPC) OS X 10.5 RESOLVED DUPLICATE 91663 P2 Normal --- 0 tobias.netzel webkit-unassigned ap barraclough fpizlo oliver oldest_to_newest 672344 0 tobias.netzel 2012-07-18 07:10:10 -0700 Although both PowerPC platform and 10.5 OS X aren't supported anymore by the WebKit project I think this crash bug should be reported because I think this is actually supposed to work. I don't know if this is reproducible on different platforms or OSes but I'd be grateful for any hints you can give me to fix this issue. Here comes the crash report: Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x00000000bbadbeef Crashed Thread: 0 Thread 0 Crashed: 0 com.apple.JavaScriptCore 0x006ea520 WTF::OSAllocator::reserveAndCommit(unsigned long, WTF::OSAllocator::Usage, bool, bool, bool) + 144 1 com.apple.JavaScriptCore 0x0057c78c JSC::JSGlobalData::JSGlobalData(JSC::JSGlobalData::GlobalDataType, JSC::ThreadStackType, JSC::HeapType) + 76 2 com.apple.JavaScriptCore 0x0057dfb4 JSC::JSGlobalData::createLeaked(JSC::ThreadStackType, JSC::HeapType) + 52 (JSGlobalData.cpp:221) 3 com.apple.WebCore 0x030d92b4 WebCore::JSDOMWindowBase::commonJSGlobalData() + 52 (JSDOMWindowBase.cpp:211) 4 com.apple.WebKit 0x0027338c +[WebCoreStatistics setShouldPrintExceptions:] + 28 (WebCoreStatistics.mm:176) 5 com.apple.dashboard.client 0x0001231c 0x1000 + 70428 6 com.apple.dashboard.client 0x00011360 0x1000 + 66400 7 com.apple.Foundation 0x90b7d684 _nsnote_callback + 196 8 com.apple.CoreFoundation 0x95882438 _CFXNotificationPostNotification + 920 9 com.apple.Foundation 0x90b7adc0 -[NSNotificationCenter postNotificationName:object:userInfo:] + 88 10 com.apple.AppKit 0x904b4854 -[NSApplication _postDidFinishNotification] + 108 11 com.apple.AppKit 0x904b476c -[NSApplication _sendFinishLaunchingNotification] + 80 12 com.apple.AppKit 0x9043c110 -[NSApplication(NSAppleEventHandling) _handleAEOpen:] + 260 13 com.apple.AppKit 0x9043b948 -[NSApplication(NSAppleEventHandling) _handleCoreEvent:withReplyEvent:] + 88 14 com.apple.Foundation 0x90b9e004 -[NSAppleEventManager dispatchRawAppleEvent:withRawReply:handlerRefCon:] + 480 15 com.apple.Foundation 0x90b9ddd8 _NSAppleEventManagerGenericHandler + 236 16 com.apple.AE 0x96b5ace0 aeDispatchAppleEvent(AEDesc const*, AEDesc*, unsigned long, unsigned char*) + 164 17 com.apple.AE 0x96b5abe8 dispatchEventAndSendReply(AEDesc const*, AEDesc*) + 40 18 com.apple.AE 0x96b5a9ec aeProcessAppleEvent + 212 19 com.apple.HIToolbox 0x933a740c AEProcessAppleEvent + 52 20 com.apple.AppKit 0x90439474 _DPSNextEvent + 1156 21 com.apple.AppKit 0x90438bfc -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 112 22 com.apple.AppKit 0x9043289c -[NSApplication run] + 744 23 com.apple.dashboard.client 0x0000ae84 0x1000 + 40580 24 com.apple.dashboard.client 0x0000221c 0x1000 + 4636 672504 1 ap 2012-07-18 10:32:49 -0700 Marking this bug as INVALID because it is not known to happen on supported platforms. I would check whether Platform.h flags are now wrong for PowerPC - CLASSIC_INTERPRETER should be enabled, but it doesn't seem to be. Also, I'm curious why it's expected for executable allocation to sometimes fail (I wish bug 81693 explained that). 672513 2 tobias.netzel 2012-07-18 10:42:53 -0700 I've got numerous patches applied to support PowerPC Mac OS 10.5 . Safari, Mail and many other applications are running well with it - it's just Dashboard that crashes. Is that code path known to work on the supported platforms? 672516 3 tobias.netzel 2012-07-18 10:43:56 -0700 I've got to add that it does work with WebKit 536.25 . 672643 4 fpizlo 2012-07-18 12:50:36 -0700 (In reply to comment #2) > I've got numerous patches applied to support PowerPC Mac OS 10.5 . Safari, Mail and many other applications are running well with it - it's just Dashboard that crashes. > Is that code path known to work on the supported platforms? This is interesting. There are at least two reasons why JSGlobalData would call reserveAndCommit(): 1) Allocate the heap. 2) Allocate executable memory. There are probably others. (2) seems totally unlikely because on PowerPC we don't have a JIT so we wouldn't be allocating executable memory unless our configuration logic is borked. If it's (1) or something else other than (2), then this crash indicates that either memory allocation failed or returned some result that we weren't happy with. I could imagine that happening if the semantics on OS X 10.5 were somewhat different enough that our current assumptions about how OS page allocation works are not valid. I would start with that, if I were you. 672682 5 oliver 2012-07-18 13:12:25 -0700 There are other things crashing like this. It seems where managing to start initialising stuff before calling Options::initialise() so we end up trying to do a 0-sized mmap for the mark stacks (and other related shenanigans) 672728 6 oliver 2012-07-18 14:04:16 -0700 I suspect I fixed this with http://trac.webkit.org/changeset/123013 673131 7 tobias.netzel 2012-07-18 21:20:58 -0700 This is indeed fixed by http://trac.webkit.org/changeset/123013 . *** This bug has been marked as a duplicate of bug 91663 ***