When I launch Webkit r21742 or r21770 it crashes immediately. It then launches fine with the Extensions disabled message. If I quit again and relaunch it will crash again. It only launches the first time after a crash. r21682 works fine.
Created attachment 14730 [details]
I guess this must not be crashing for others. Crashing continues through r21805.
(In reply to comment #2)
> I guess this must not be crashing for others.
That's correct - r21794 doesn't crash for me.
(In reply to comment #3)
> That's correct - r21794 doesn't crash for me.
Are you running PPC or intel? I'm PPC.
OK, it appears this is related to Bug 13661 in which I had problems loading a stylesheet. Now if I have a Stylesheet set in the Advanced prefs, Webkit crashes on launch. Setting the stylesheet to none removes the problem. Even setting it to a blank css file brings back the crashing.
(In reply to comment #5)
> OK, it appears this is related to Bug 13661 in which I had problems loading a
> stylesheet. Now if I have a Stylesheet set in the Advanced prefs, Webkit
> crashes on launch. Setting the stylesheet to none removes the problem. Even
> setting it to a blank css file brings back the crashing.
That doesn't make it crash for me.
Does the crash log indicate anything useful for me to look at? I've tried a variety of system maintenance, removed plugins/extensions, etc. and nothing effects the crashing other than not selecting a css file.
Also, as with Bug 13661, the crashing only occurs when I'm using the latest Nightly build that loads the Webkit Start page. For some reason when I run a previously crashing version after a new Nightly is released, I no longer see the start page, but the crashing also goes away. Same thing happened with Bug 13661 where my css wasn't loading, but reverting back a version would work.
Okay, so I opened the package contents of the latest Webkit and renamed the start.html so it wouldn't load. Now when launching Webkit I get the expected file not found error, but no crash and my stylesheet works fine which resolves the issue for both bugs.
So, since some of you make custom builds, be sure you try with the latest nightly that loads the Start page to see if you can duplicate it.
If you reference the other bug, you'll see the I started having the css loading issue somewhere around r21367 in which someone referenced it as "Looks like more fallout from Maciej's change in r21367 (nothing else in the r21359-r21368 range looks like it could have caused it)."
To my eyes there's something up with the initially loading of that start page as it relates to preference set css.
One further note. I don't think it's the start page itself since I can create a blank start.html and it will crash. Looks like it's related to the code that calls the Webkit special start page to begin with.
Kevin, there are a lot of third-party Input Managers, APEs, haxies, etc. installed on your system. Try disabling/removing them to see if it still crashes (while it's reproducible):
0x1f4000 - 0x1fbfff alex_lagutin.audio_hijack.server 1.3.3 /Library/Application Enhancers/Instant Hijack Server.ape/Contents/MacOS/Instant Hijack Server
0x705000 - 0x72ffff com.unsanity.windowshadex.cocoa 4.1.2 (???) /Users/kdean/Library/Application Enhancers/WindowShade X.ape/Contents/PlugIns/WindowShade X Cocoa.ape/Contents/MacOS/WindowShade X Cocoa
0x1848000 - 0x187ffff com.unsanity.fruitmenu 3.6.4 (204) /Users/kdean/Library/Application Enhancers/FruitMenu.ape/Contents/MacOS/FruitMenu
0x1b53000 - 0x1b54fff com.ecamm.pluginloader Ecamm Plugin Loader v1.0.5 (1.0.5) /Library/InputManagers/Ecamm/Ecamm Plugin Loader.bundle/Contents/MacOS/Ecamm Plugin Loader
0x1b58000 - 0x1b5ffff com.unsanity.smartcrashreports Smart Crash Reports version 1.0.2 (1.2) /Library/InputManagers/Smart Crash Reports/Smart Crash Reports.bundle/Contents/MacOS/Smart Crash Reports
0x1715a000 - 0x17181fff com.stuffit.StuffItCM 11.0.2 /Library/Contextual Menu Items/StuffItCM.plugin/Contents/MacOS/StuffItCM
0x1719d000 - 0x171e9fff com.stuffit.sdk 11.0.2 /Library/Frameworks/StuffIt.framework/Versions/B/StuffIt
0x17244000 - 0x172f2fff com.stuffit.stuffitcore 11.0.2 /Library/Frameworks/StuffItCore.framework/Versions/A/StuffItCore
0x173da000 - 0x173f3fff com.abracode.FileUtilsCM FileUtilsCM version 1.7.2 (1.7.2) /Users/kdean/Library/Contextual Menu Items/FileUtilsCM.plugin/Contents/MacOS/FileUtilsCM
0x17404000 - 0x17405fff com.stairways.interarchy.cmplugin 7.0 /Users/kdean/Library/Contextual Menu Items/InterarchyCMPlugIn.plugin/Contents/MacOS/InterarchyCMPlugIn
0x17408000 - 0x17409fff net.brockerhoff.Nudge.CM 1.1 /Users/kdean/Library/Contextual Menu Items/Nudge.plugin/Contents/MacOS/Nudge
0x1740c000 - 0x17451fff com.abracode.OnMyCommandCM 1.8 /Users/kdean/Library/Contextual Menu Items/OnMyCommandCM.plugin/Contents/MacOS/OnMyCommandCM
0x17479000 - 0x1747afff uk.co.markallan.clamxav.ScanWithClamXav ??? (1.0) /Users/kdean/Library/Contextual Menu Items/ScanWithClamXav.plugin/Contents/MacOS/ScanWithClamXav
0x1747d000 - 0x17485fff com.roxio.ToastItPlugin ToastIt 1.1.2 (build 17) (1.1.2) /Users/kdean/Library/Contextual Menu Items/ToastIt.plugin/Contents/MacOS/ToastIt
(In reply to comment #10)
> Kevin, there are a lot of third-party Input Managers, APEs, haxies, etc.
> installed on your system. Try disabling/removing them to see if it still
> crashes (while it's reproducible):
I've disabled a bunch of them with no effect. I'll post another crash log to see if anything else is remaining. I also logged in as root and it crashes there too.
Created attachment 14761 [details]
Crash log 2
(In reply to comment #11)
> I've disabled a bunch of them with no effect. I'll post another crash log to
> see if anything else is remaining. I also logged in as root and it crashes
> there too.
Have you tried creating a new user on the same computer? Does it still crash with the new user?
Have you tried loading the WebKit nightly with your local CSS stylesheet disabled to see if that fixes the crash?
If that does fix the crash, could you post your CSS stylesheet so others may attempt to reproduce it?
(In reply to comment #13)
> (In reply to comment #11)
> Have you tried creating a new user on the same computer? Does it still crash
> with the new user?
Yes and it still crashes. I've also confirmed that reverting to r21682 and getting the start page to load by deleting the webkit plist removes the problem. Reinstall r21742 and the crashing returns.
(In reply to comment #14)
> Have you tried loading the WebKit nightly with your local CSS stylesheet
> disabled to see if that fixes the crash?
> If that does fix the crash, could you post your CSS stylesheet so others may
> attempt to reproduce it?
See Comment #5 above. Basically having no stylesheet does remove the problem and it doesn't matter what stylesheet is used. I created an empty file and pointed it and it crashed. Renaming the start.html has mentioned in Comment #8 also keeps it from crashing.
Confirmed with WebKit Nightly r21834!
* STEPS TO REPRODUCE:
1. Create an empty stylesheet on the desktop: touch ~/Desktop/foo.css
2. Launch WebKit nightly (I used my local debug build) and set the user stylesheet to ~/Desktop/foo.css.
3. Quit WebKit nightly/local debug build.
4. Delete ~/Library/Preferences/org.webkit.nightly.WebKit.plist so the start page loads.
5. Double-click on WebKit nightly launcher.
This regressed between WebKit nightly r21682 and r21742 as Kevin previously mentioned.
Stack is similar to those already posted. Looks like a null pointer dereference.
Taking the latest crashing nightly and replacing the following files from the previous non-crashing nightly also removes the problem. Had to replace both since they were dependent on each other. Doesn't really help narrow things down but it really seems to me that some non-local to my machine changed between the versions r21682 & r21742 since I can revert in various ways and not have the issue. Remember also that my initial issue with the css file as described in the other bug started around r21367. I'll try some prior nightlies to see if it started earlier than r21367.
(In reply to comment #18)
Remember also that my initial issue with the css file as described in
> the other bug started around r21367. I'll try some prior nightlies to see if it
> started earlier than r21367.
Just confirming my initial problem described in Bug 13661 does occur with r21368 and r21359 worked fine.
(In reply to comment #19)
> (In reply to comment #18)
> Remember also that my initial issue with the css file as described in
> > the other bug started around r21367. I'll try some prior nightlies to see if it
> > started earlier than r21367.
> Just confirming my initial problem described in Bug 13661 does occur with
> r21368 and r21359 worked fine.
If Bug 13661 doesn't occur anymore (but this one does), please close it. Thanks!
(In reply to comment #20)
> If Bug 13661 doesn't occur anymore (but this one does), please close it.
I've closed it but will keep an eye out in case it return when this one is resolved.
*** Bug 13911 has been marked as a duplicate of this bug. ***
Thats where this broke.
That change was extremely important, we'll have to fix it
Fixed in r21952
*** Bug 14201 has been marked as a duplicate of this bug. ***