Bug 91622 – Launching the Dashboard causes a crash in JSGlobalData()

• Status: RESOLVED
• Resolution: DUPLICATE
• Component: JavaScriptCore

[Tobias Netzel]

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

[Alexey Proskuryakov]

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

[Tobias Netzel]

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?

[Tobias Netzel]

I've got to add that it does work with WebKit 536.25 .

[Filip Pizlo]

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

[Oliver Hunt]

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)

[Oliver Hunt]

I suspect I fixed this with http://trac.webkit.org/changeset/123013

[Tobias Netzel]

This is indeed fixed by http://trac.webkit.org/changeset/123013 .

*** This bug has been marked as a duplicate of bug 91663 ***