Bug 91622
Summary: | Launching the Dashboard causes a crash in JSGlobalData() | ||
---|---|---|---|
Product: | WebKit | Reporter: | Tobias Netzel <tobias.netzel> |
Component: | JavaScriptCore | Assignee: | Nobody <webkit-unassigned> |
Status: | RESOLVED DUPLICATE | ||
Severity: | Normal | CC: | ap, barraclough, fpizlo, oliver |
Priority: | P2 | ||
Version: | 528+ (Nightly build) | ||
Hardware: | Mac (PowerPC) | ||
OS: | OS X 10.5 |
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
Attachments | ||
---|---|---|
Add attachment proposed patch, testcase, etc. |
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 ***