About a month ago, the nightly builds incorporated a code change that caused WebKit to crash on launch. Being a lazy bum, I went back to the October 25 build, which still works fine. I had been updating WebKit daily (or more often) prior to that time, and I hoped the WebKit builds would work through whatever bug was bringing it down without a report from me. No such luck. I downloaded the latest nightly just now, and it crashed before the WebKit home page ever got around to loading. Whatever the problem is, it doesn't affect Safari, WebKit prior to October 26, or Safari 3.0 as of the latest Leopard build (November 9). As usual, I suspect an InputManager problem, but I'm not really willing to live without any of the following Safari plugins that I use, none of which use SIMBL as I've installed them: - SafariStand - SafariTidy - Creammonkey - SafariBlock - Inquisitor I also have SurfRabbit installed, but I'm removing that and will test WebKit without it. There are other InputManagers I use that aren't specifically for Safari, but which add value to my entire library of Cocoa apps. It's probably best to start by evaluating the above list, however. I'll try to find time to test these out as well, but in the meantime I wanted to get the bug recorded, since it means I can't use the WebKit nightlies anymore. Regards, Leland
Can you please attach the crash log? Its not clear from your report whether you have tried disabling all extensions (including SIMBL, Application Enhancers, and input manager bundles) -- if you have not, can you please try this and confirm whether the problem is in WebKit or the extensions.
For reference, if the crash is caused by an extension then the bug should be reported to the author of the extension rather than filed against WebKit. There isn't a lot we can do to prevent bugs in code loaded into WebKit-using applications from bringing down the application.
I will disable InputManagers and try WebKit again (sorry if I was unclear about this), but I haven't done that yet. Regarding your first comment, however, despite my huge sympathy for the WebKit team (as my writings about it clearly indicate), that's a big cop-out that won't help WebKit in the long run. If popularly used Safari plugins cause WebKit to crash, but not Safari, the fault from the user's perspective is clearly with WebKit. To point the finger at plugin makers doesn't help the main problem: WebKit won't run. in the past, when SIMBL plugin AcidSearch caused WebKit to crash, I wrote to the developer of both SIMBL and AcidSearch, but ultimately had to stop using both of those plugins. That's not going to go over well with the Safari user base in the long run. I'll write back when I have a chance to test WebKit without the plugins. In the meantime, I'll post some of the crash log. (In reply to comment #2) > For reference, if the crash is caused by an extension then the bug should be > reported to the author of the extension rather than filed against WebKit. > There isn't a lot we can do to prevent bugs in code loaded into WebKit-using > applications from bringing down the application. > (In reply to comment #2) > For reference, if the crash is caused by an extension then the bug should be > reported to the author of the extension rather than filed against WebKit. > There isn't a lot we can do to prevent bugs in code loaded into WebKit-using > applications from bringing down the application. >
When I attach the debugger to WebKit as it crashes, here is the output: Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000000 Reading symbols for shared libraries ............ done /Users/llscotts/21088: No such file or directory. Attaching to program: `/Applications/Safari.app/Contents/MacOS/Safari', process 21088. Reading symbols for shared libraries ................................................................................................................................................................................. done Reading symbols for shared libraries ............................ done 0x00328210 in -[WebFrame frameElement] () Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x00000000 0x00328210 in -[WebFrame frameElement] () (gdb) Before disabling all InputManagers, I disabled each one mentioned in the Console log as WebKit crashes, in the following order: SafariScript, Creammonkey, Cocoa TextSelectionHelper, and Inquisitor. Removing these doesn't solve the problem, and WebKit crashes with the following statement in Console log: 2006-11-25 11:27:11.751 WebKit[23322] Error swizzling 2006-11-25 11:27:11.751 WebKit[23322] Couldn't find orig 2006-11-25 11:27:11.751 WebKit[23322] Couldn't find alt 2006-11-25 11:27:11.751 WebKit[23322] Error swizzling 2006-11-25 11:27:11.751 WebKit[23322] Couldn't find orig 2006-11-25 11:27:11.751 WebKit[23322] Error swizzling 2006-11-25 11:27:11.751 WebKit[23322] Couldn't find orig Nov 25 11:27:13 musicroom crashdump[23339]: Safari crashed Nov 25 11:27:14 musicroom crashdump[23339]: crash report written to: /Users/llscotts/Library/Logs/CrashReporter/Safari.crash.log After this, I disabled InputManagers by renaming the folder, and WebKit runs. However, clearly there's something wrong with WebKit if you have to disable all InputManagers in order for it to run. It needs to be able to "survive" in the real world... Hope this helps... Leland P.S. Remember, this error only cropped up after October 25. Prior to that, WebKit worked fine. I think there may be a problem in the way WebKit is disabling plugins it doesn't like as it launches. Also, what is "swizzling"?
WebKit is a piece of code used by many applications. I believe what you are referring to as "WebKit" is WebKit.app in the nightly builds -- this simply launches Safari with an updated copy of the WebKit framework. The way Safari extensions work is typically by modifying (patching) code at runtime. If the code that they hook into changes, the extension will not behave as expected. In most cases extensions are poorly coded so not behaving as expected becomes equivalent ends up being a crash. There are several well-designed Safari extensions that do things properly, and thus will _not_ crash when WebKit is updated. They typically do this by performing version checks on both the application and any frameworks that they interact with, and if they detect a newer version than they were developed against they simply refuse to work rather than risking a crash. I can think of two reasons why you'd be seeing a crash with a nightly build of WebKit but not with released Safari 2.0, or a Safari 3.0 seed: 1) A piece of code that the extension hooks has been reworked very recently, or 2) The extension causing you problems version checks only the Safari application, and not the frameworks it hooks. In this case it cannot tell the difference between Safari 2.0 with system WebKit and Safari 2.0 with a nightly build of WebKit, while it can tell the difference between Safari 2.0 and 3.0. Its very likely that it would be silently disabling itself in the case of Safari 3.0. There is nothing we can do _but_ have extension developers fix their extensions. We can't simply stop working on WebKit completely out of fear of breaking badly coded extensions, all of which are third-party components that are (ab)using the input management functions of Mac OS X to run arbitrary code inside another application. We have absolutely no control over what these extensions do, so there is nothing that we can do to stop extensions from causing crashes. Yes, crashes are bad. No, blaming WebKit isn't going to make it stop happening as its not something we can control.
The "Error swizzling" and "Couldn't find ..." messages are from one of the extensions that is being loaded, quite possibly the one that is causing the crash. Can you please provide a backtrace from that crash? When stopped at the GDB prompt as shown in your output, type bt and hit enter. That will provide the information needed to see the context in which this crash has occurred. > After this, I disabled InputManagers by renaming the folder, and WebKit runs. > However, clearly there's something wrong with WebKit if you have to disable all > InputManagers in order for it to run. It needs to be able to "survive" in the > real world... An extension is able to execute any code that it wants in the same process and address space that the WebKit framework runs in. It can do basically _anything_, including exiting, crashing, or changing the behaviour of existing code. If the extension changes the behaviour of existing code in such a way that it breaks invariants that WebKit expects to hold and eventually leads to a crash, this is definitively not a bug in WebKit. > P.S. Remember, this error only cropped up after October 25. Prior to that, > WebKit worked fine. I think there may be a problem in the way WebKit is > disabling plugins it doesn't like as it launches. Also, what is "swizzling"? WebKit doesn't disable any "plugins" on launch. It tells the Mac OS X runtime to prefer the bundled WebKit frameworks over the ones in /System/, and then launches Safari. It looks for bundles that are loaded into Safari so that it can warn users to disable them before filing bug reports about the crashes that they cause, which we have little to no ability to address.
I'm closing this bug as INVALID, as the information you have provided so far suggests the problem is very likely caused due to a Safari extension. If you think that Safari should manage extensions in a better fashion, I would encourage you to file a bug report over at http://bugreporter.apple.com/. I would appreciate if you could still attach the crash log from the crash you are experiencing so that I can verify my diagnosis is correct.
I'll get back to you tomorrow (er, later today) with more details. Bottom line, you're right... the problem is some InputManager conflict involving 2 or 3 specific plugins. Once I sort it out, I'll post info here and also send a notice to the plugin developers. Regarding how WebKit/Safari handles plugin conflicts, I'll try to write up a suggestion for Apple. Obviously, you don't want bad plugins to create a bad impression of your browser, but that's invariably what happens... at least with WebKit. (I've never--or very rarely--had this problem with Safari over the years.) Leland
I would suggest that you should be clear in your bug report to Apple that you are referring to Safari extensions rather than Safari plugins -- plugins are things like QuickTime, Flash, etc, that handle various extra content types in any WebKit application. Extensions and plugins are similar in that they both allow arbitrary code to be executed in the parent process, but differ in the mechanism involved and the official support that is provided. Thanks for your patience.
Created attachment 11637 [details] Crash log for webkit
Hi again,I've attached the crash listing for WebKit from this morning... I'm working in the latest Leopard client seed today, but this is from the WebKit nightly. The problem extensions appear to be the following: - SafariStand 2.0beta v16 and v17 - SafariBlock 1.14 - Safaritidy 0.2.1 The first two bundles can run if the other isn't also loaded, whereas safaritidy causes a crash no matter what other extensions are loaded with it. By the way, extensions that appear to be completely "good citizens" in this scenario include (these aren't necessarily exclusively Safari extensions): - CocoaTextSelectionHelper (abracode) - HotService (devon technologies) - Inquisitor (david watanabe) - SafariScript (nadamac.de) - Smart Crash Reports (unsanity) - SIMBL (mike soloman) - SetAlphaValue (mparrot) - TextExtras (mike ferris) I'll notify the three "bad" extension authors about the problem. Thanks for the semantics lesson, by the way. I knew that architecturally extensions were different from plugins (look at the "Installed Plugins" page in Safari...), but I just haven't been disciplined about using the proper terminology. :-) Hope this helps a little bit... Cheers, Leland
For what it's worth, SafariTidy 0.2.1 works for me in the nightly without any crashes.
(In reply to comment #12) > For what it's worth, SafariTidy 0.2.1 works for me in the nightly without any > crashes. > FYI, I got an email last night from safaritidy's author confirming the problem... he says, "I've looked at the problem, and can reproduce the crash." He worries the problem may involve the whole InputManager API, but I'll assure him that many others don't cause WebKit to crash. Do you have SafariTidy installed as a SIMBL plugin, or as a "straight" InputManager? I have mine configured the latter way...
I simply followed the instructions in the README on how to install it. Thanks for following up with the authors of those extensions, hopefully they are able to resolve the issues.