Beginning with build r173995, webkit is crashing every time I try to open it. I get spinning beachball on my cursor. I have to do force quit, and cannot use at all. Does same with newer build. I rolled back to build 173971, and it works fine. Not sure what component this should be under.
I cannot reproduce this with r173995 and Safari 7.1. Which version of Safari are you using the nightly with? Please attach a crash log: <http://www.webkit.org/quality/crashlogs.html>.
Safari version 7.1 Just tried the newest build and still doing the same thing. build 174034 Using build 173791 with no problems. I'm not getting the crash reporter dialog box. As soon as I try to open webkit, I start getting the spinning beachball. Then I have to force quit.
Can you find anything that would seem relevant in Console.app? There could be something in console output, and/or crash and spin logs for WebContent process. The information is a bit scattered, so you'd need to open a few disclosure triangles and look for anything that's related to Safari or WebContent and has a timestamp close to when you observe the problem.
Sending an attachemnt of the console info that posted when I tried to load your newest version.
Created attachment 238827 [details] console report from when I tried to install your newest build (see comment right before this)
Thank you! We've got another report of similar behavior (bug 137196), and it sounds like this happens when AdBlock is installed. Could you please try disabling extensions to see if that helps? Stack trace of a frozen main thread: 30 JSC::HeapTimer::timerDidFire(__CFRunLoopTimer*, void*) + 169 (JavaScriptCore) [0x1089cad09] 30 JSC::GCActivityCallback::doWork() + 135 (JavaScriptCore) [0x10880ae77] 30 JSC::Heap::collect(JSC::HeapOperation) + 359 (JavaScriptCore) [0x1089c6727] 30 JSC::Heap::suspendCompilerThreads() + 70 (JavaScriptCore) [0x1089c6a26] 30 JSC::DFG::Worklist::suspendAllThreads() + 83 (JavaScriptCore) [0x108958433] 30 __psynch_mutexwait + 10 (libsystem_kernel.dylib) [0x7fff96751746] *30 psynch_mtxcontinue + 0 (pthread) [0xffffff7f80b51a3b] And another thread is doing this, somehow trying an failing to crash, it seems: 30 JSC::FTL::LowerDFGToLLVM::compileNode(unsigned int) + 919 (JavaScriptCore) [0x10897d007] 30 JSC::FTL::LowerDFGToLLVM::compileCallOrConstruct() + 3330 (JavaScriptCore) [0x1089946d2] 30 JSC::FTL::LowerDFGToLLVM::lowJSValue(JSC::DFG::Edge, JSC::DFG::OperandSpeculationMode) + 749 (JavaScriptCore) [0x10899c26d] 30 JSC::DFG::Graph::handleAssertionFailure(JSC::DFG::Node*, char const*, int, char const*, char const*) + 482 (JavaScriptCore) [0x10889f6c2] 30 WTFCrash + 62 (JavaScriptCore) [0x108c26f8e]
Hi, I disabled adblock and now it works. Disappointing since adblock is a good extension. Thanks for your help!
*** Bug 137196 has been marked as a duplicate of this bug. ***
<rdar://problem/18501821>
This bug continues in the Oct 1 build, unfortunately. AdBlock and Adblock Pro both. The app doesn't crash- it never starts and needs to be force quit.
Still not resolved with nightly r174148 delivered 10/01.
Seems to work for me today (10/2) on r174204.
"Seems to work for me today (10/2) on r174204." It does indeed work with AdBlock enabled, but not with AdBlock Plus enabled. What's the difference? Anyway, they're half-way there.
The 10/8 nightly (and some previous) resolves the AdBlock problem, but not the Adblock Plus problem. I've abandoned Webkit now and will wait for the full resolution, if it ever comes.
(In reply to comment #14) > The 10/8 nightly (and some previous) resolves the AdBlock problem, but not > the Adblock Plus problem. I've abandoned Webkit now and will wait for the > full resolution, if it ever comes. I am trying AdBlock Plus on r179573 and I have not been able to reproduce the problem so far. Could you please try a recent Nightly? If you still get the crash, could you give the list of installed extensions? I only have AdBlock Plus and RES, you may have something else causing more load than on my machine. Another data point that could be useful is the list of filters you subscribe to. It looks like the blocking is on GC, it may be only reproducible with large filter list.