The summary says it all, really. It's completely trivial, because all you need to do is quit Safari and restart System Preferences, but still a bit of a curiosity. Also, after attaching gdb to it, then detaching, it stopped crashing, even through multiple invocations of System Preferences and various sacrifices to try to get a backtrace again. Divine touch of gdb? PID: 9207 Thread: Unknown Link (dyld) error: Symbol not found: _objc_msgSendSuper Referenced from: /System/Library/PreferencePanes/Mac.prefPane/Contents/MacOS/Mac Expected in: /Applications/WebKit.app/Contents/Resources/WebKit.framework/Versions/A/WebKit
Backtrace! (gdb) backtrace #0 0x8fe0416c in __dyld__ZN4dyld14bindLazySymbolEPK11mach_headerPm () #1 0x8fe15678 in __dyld_stub_binding_helper_interface () #2 0x055709bc in std::locale::id::id_count_s () #3 0x94517290 in -[NSPrefPaneBundle instantiatePrefPaneObject] () #4 0x00006808 in ?? () #5 0x00006504 in ?? () #6 0x928c5998 in __NSFireDelayedPerform () #7 0x9076bdb0 in __CFRunLoopDoTimer () #8 0x90758728 in __CFRunLoopRun () #9 0x90757cdc in CFRunLoopRunSpecific () #10 0x93161be0 in RunCurrentEventLoopInMode () #11 0x931611ec in ReceiveNextEventCommon () #12 0x931610e0 in BlockUntilNextEventMatchingListInMode () #13 0x9365c704 in _DPSNextEvent () #14 0x9365c3c8 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] () #15 0x9365890c in -[NSApplication run] () #16 0x93749284 in NSApplicationMain () #17 0x00002d04 in ?? () #18 0x0000a348 in ?? ()
I cannot reproduce this. The dyld error you provided says that the .Mac preference pane is trying to look up objc_msgSendSuper in the WebKit framework inside another app bundle. This seems like a nonsensical thing to do. The only reason I can think of is that you've some launched System Preferences in such a way that it's using the newer WebKit. Are you able to provide more information, such as the full crash report or instructions on how to reproduce this?
I'm not invoking System Preferences in any irregular way, and this only occurs if WebKit.app from Nightshift is running at the time (I thought I had mentioned this initially - bad!). Unfortunately, there's nothing more to the crash logs than what I posted. Like I said, this is something really trivial, and is more of a weird novelty bug than anything else. In fact, it's probably not even a bug in WebKit at all, but some manifestation of dyld weirdness.
There is more to the crash report that is of interest than just the backtrace. When the dialog comes up informing you that System Preferences has crashed, click on Report. Copy & Paste the entire contents of the pane containing the crash report. It contains relevant information such as what libraries have been linked into the crashed process. How are you running System Preferences? Are you clicking on it in the Dock, launching it via Quicksilver/ LaunchBar or similar, etc?
Seems highly unlikely that Safari running in a separate process is able to cause this problem with the .Mac preferences pane, unless you opened preferences using a button inside Safari. If you did, then the DYLD_FRAMEWORK_PATH that was used to start up Safari could mean that System Preferences will run with various other frameworks that you built rather than the system versions. And that could cause trouble.
Darin's guess was bang on. Launching System Preferences from the 'Change Settings...' buttons in Safari's Advanced preference pane, and then clicking through to .Mac preferences yields the dyld error. After discussing this on IRC the proposed solution is to have the nightly builds set an extra environment variable which WebKit will check for, and reset DYLD_FRAMEWORK_PATH if it is set.
Created attachment 3856 [details] Patch to have WebKit clear DYLD_FRAMEWORK_PATH
Created attachment 3857 [details] Updated patch without two irrelevant changes in project file.
Comment on attachment 3857 [details] Updated patch without two irrelevant changes in project file. Hooray! Great trick. (Waits for Maciej to tell him why it's no good.)