All my browsers crash constantly! Need help to keep my sanity

While browsing I continually get the pinwheel and have to force close the browser. Happens with firefox, safari, and chrome will not even launch anymore. Just sits there and bounces until it crashes. Seems to happen most when I open a new page.


It started happening out of the blue about 5 months ago. Happens probably every 20 - 30 minutes (I do keep a lot of tabs open, if that is relevant). I've tried reinstalling the browsers, different OS installs, time machine restores from when things were working, and multiple system wipes and starting from scratch..... SAME PROBLEM


MacBook Pro (15-inch, Mid 2010)

2.4 GHz Intel Core i5

8 GB 1067 MHz DDR3

Intel HD Graphics 288 MB

OSX 10.11.2


Could this be a hardware issue? Logic board failure or something of the like?


The next time I see the pinwheel, I may just chuck the thing out the window. Would greatly appreciate some help!

MacBook Pro

Posted on Jan 30, 2016 10:16 AM

Reply
64 replies

Feb 16, 2016 7:58 AM in response to Seanothon

Hello again Seanothon,

Adware is bad in many ways. It is considered a "sensitive topic" here on Apple Support Communities because it often causes threads to go off-topic into tangents about the relative effectiveness of various anti-adware tools. When this happens, the original poster usually flees the melee. You are a bit unusual because you haven't given up yet. I'm not ready to give up yet either. There are still some basic troubleshooting steps that you can try that haven't been suggested yet. (Doh! No, it appears I did suggest them. 🙂 )


Unfortunately, there is still no evidence that your machine is adware-free. You did have the "Spigot" adware. You also had two Safari adware extensions. EtreCheck only reports Safari extensions so you could also have Firefox and/or Chrome adware extensions too. And you have Google Drive as a login item, which could complicate things.


One way to easily simplify the situation is to create a new user account on your machine using the procedure I described a couple of weeks ago. Log out of your current account and log in to the new user account. Safe Mode is really a waste of time because it is so radically different than normal usage. Creating a new user account is really the best way to isolate problems that may only exist inside a user account. If you have the same problem in a new user account, then the cause must be at the system or hardware level.


If the problem is restricted to your current user account, then I suggest downloading the latest version of EtreCheck and trying it again. Since you started this thread, I have made some significant upgrades to EtreCheck. It will now delete these adware files for you. Plus, you mentioned that the problem started 5 months ago (well, maybe 6 months ago at this point). The most recent version of EtreCheck also includes the likely install date for any system modifications. If one of those dates corresponds to the beginning of your problem, then that entry might be the cause.

Feb 17, 2016 5:55 PM in response to Seanothon

Seanothon wrote:


Created a new user profile. Issue still persists. So, I'm probably looking at a hardware issue here?

Hello again Seanothon,

Yes. It could also be a system-level issue. Unfortunately, you don't seem to have many system-level modifications, so that also suggests a hardware problem.


I would like to see the crash and hang logs for plugin-container, Firefox, and Chrome. I have had a couple of people report crashes of EtreCheck that were due to an old program that injected itself into other app's dynamic libraries. It doesn't really look like that is the case with your problem, but it doesn't hurt to look.


There is one more thing you can try. Turn off your WiFi card and connect to your or some other router with an Ethernet cable. Do you see the same problem. And now that I think about it, have you tried a different router?

Feb 17, 2016 9:27 PM in response to Seanothon

Have you started to explore the possibility? I realize that several folks have said there's no indications from the diagnostics to date, but if you still believe that's a possibility you should check your boot drive with a quality utility such as SMART Utility or DriveDX. For the rest of the computer run the Apple Hardware Test that came on your Snow Leopard Installation disk 2.

Feb 18, 2016 5:36 AM in response to Seanothon

So, I'm probably looking at a hardware issue here?

Most likely.


I believe that the diagnosis at an Apple Store (if you have one near enough to you) is still free. The consumer grade hardware test available to you is pathetic in comparison to the diagnostic tools they have available. The AHT will often come up with an overall negative result, even when Apple diagnostics would find a serious hardware fault. No harm in running the two drive checking utilities that MadMacs0 suggested, but, any more than that, I don't think you should pursue any more time wasting experiments.


If it were my Mac, that's what I would do, and would already have done, some time ago. They may give it back to you saying they can't find anything wrong, and then you can continue the experiments, but at least that way you will have ruled out the most likely possibility.

Feb 18, 2016 7:05 AM in response to MadMacs0

MadMacs0 wrote:


Have you started to explore the possibility? I realize that several folks have said there's no indications from the diagnostics to date, but if you still believe that's a possibility you should check your boot drive with a quality utility such as SMART Utility or DriveDX.

A general comment on these two programs, not meant for Seanothon specifically, who I still think should just bring it in for a proper diagnosis:


I may at one point have also been recommending SMART Utility to users here, but I would no longer particularly endorse any program, despite its claims that it may use some kind of advanced algorithm, which basically depends on SMART monitoring--notoriously unreliable as a predictor of current or future drive health.


Might want to directly install smartmontools and, for what it's worth, interpret the data oneself.


First, install brew:


http://brew.sh/


Then, from the command line, “brew install smartmontools


Then from the command line: smartctl -s on -a disk0s3

(disk0s3 is specific to my setup, it's my 10.8 volume. Get the proper disk identifier from "diskutil list")

Feb 18, 2016 11:30 AM in response to WZZZ

I started out using smartmontools and was not impressed, which is exactly what brought me to SMART Utility. It uses smartmontools to obtain it's information and it clearly applies an algorithm to predict drive failure. It has always warned me long before SMARTReporter, TechTools Pro, Drive Genius and the lowly Disk Utilities of impending doom. The only thing I found that was better at the time was SoftRAID which warned me a couple of hours before SMART Utility that I needed to immediately replace my internal drive. DriveDx was not available at the time, but I do prefer their display. The folks I work with would probably rank SoftRAID Lite first, DriveDx and SMART Utility over anything else today.


Now to home-brew. I tried it once for something and have no interest in ever going there again. It was a bear to remove, even when I followed their rather complicated instructions for doing so. But that's not the biggest problem.


Homebrew is widely known to cause problems with 3rd party software because of its insistence on making the /usr/local directory insecure. Homebrew changes permissions on ALL subdirectories of /usr/local.


When asked why they do it this way, the people behind Homebrew said they chose convenience over security. i.e. they don't want their users to have to enter an admin password to perform updates. The unfortunate side-effect is that with the way Homebrew leaves the permissions on /usr/local, anyone can write to that directory and replace any of the apps/tools you've installed - not just Homebrew tools.


You may want to consider changing to darwinports or some alternative that doesn't put convenience above security.


The reason I know this is because Homebrew users are unable to use ClamXav when it attempts to install and use it's ClamAV scan engine in /usr/local/.

Feb 18, 2016 11:58 AM in response to MadMacs0

Homebrew is widely known to cause problems with 3rd party software because of its insistence on making the /usr/local directory insecure. Homebrew changes permissions on ALL subdirectories of /usr/local.

Just had a look there, and I'm seeing that a few items, including the brew executable, in /usr/local, have my admin user (from which I authenticate) as the owner. A few have my standard user (from which I normally run) as owner, but most are owned by root. Had an older ClamXav there from 2013, owned by root--brew since installed--and just updated ClamXav from a prompt after opening it again after all this time. No problem updating it, and still shows as owned by root, despite the presence there of brew.


Don't care, since I don't really need it (run Sophos and may run VirusBarrier Express or Malwarebytes for Mac, if needed, for possible post- infection scanning), but quite surprised to see that it's no longer free. Guess that might have happened quite some time ago. Not everything can run free, and maybe this way it's a better product.


Your report on SMART Utility is interesting. The only time I ever ran it was when I first got this iMac in 2010, and it produced gibberish. But gave it the benefit of the doubt and recommended it on ASC for some time for those with suspected impending drive failures.

Feb 18, 2016 1:14 PM in response to WZZZ

It's a bit too complicated to go into all the details, but the problem comes when Homebrew complains that ClamXav has reset /usr/local/ to drwxr-xr-x root:wheel. The troubleshooting instructions here tell the user to run sudo chown -R $(whoami) /usr/local which recursively changes everything within /usr/local and breaks some of ClamXav's update capability. We've been instructing users who insist on staying with Homebrew to simply not use the "-R" option and when updating Homebrew to re-install ClamXav after.

Feb 18, 2016 1:36 PM in response to MadMacs0

MadMacs0 wrote:


Homebrew is widely known to cause problems with 3rd party software because of its insistence on making the /usr/local directory insecure. Homebrew changes permissions on ALL subdirectories of /usr/local.

That's interesting. I've always stayed away from such things, from Fink to MacPorts to Homebrew. If I needed something, I built it. These days, for most typical uses, I recommend that people just use Linux in a VM instead.


As for SMART monitoring, the problem there is that all of the variables that it monitors are proprietary to specific disks of specific manufacturers. The only time a report has any meaning is when you have the raw data in front of you and a hardware engineer from the manufacturer of your disk sitting next to you. Otherwise, it is gibberish. I assume, or at least hope, that Apple's built-in SMART monitoring is accurate for the drives that Apple uses. But if you swap out your drive, all bets are off. Generally, I just replace my (mechanical) hard drives every two years, like brakes on the car. In both cases, it is cheaper and easier to manage a scheduled replacement than an unexpected crash. I don't know about SSDs yet.

Feb 18, 2016 4:22 PM in response to etresoft

First, my apologies to the OP for taking this discussion off track for awhile. Hopefully we've given enough things for you to check so this isn't distracting you.


I've been a casual user of MacPorts for many years, just to grab a couple of things and keep them up-to-date. Never caused me any issues until I added Homebrew. As I said before, I ended up opting out of the latter. I do compile a few other things from source when necessary.


I believe most of the parameters are documented @ https://en.wikipedia.org/wiki/S.M.A.R.T., which is what I've always used as a reference. The proprietary ones have started to creep in with the advent of SSD's and I don't know whether all the utilities have managed to make the adjustments necessary to make reliable predictions.


There is also a comparison of S.M.A.R.T.tools @ https://en.wikipedia.org/wiki/Comparison_of_S.M.A.R.T._tools, but it's never included anything but smartmontools and Disk Utility for OS X and as you will see they don't know much of anything about how DU works, except what it doesn't do.


In the old days the original utilities only checked and reported the results of the last self-test conducted by the drive. I would hope that DU now does more than that, but I'm not convinced.


TechTools Pro displays a number of variables (18-24 for the drives I'm currently using) on sliding Pass to Fail graphics.


You may be right about SMART Utility as it's not showing me any of the attributes for my new Glyph Studio drives (Core Storage), even though it shows an overall PASSED. Does seem to be working with all the other drives I have, and yes I do have SATSMART 0.8/0.81 loaded. I have a contact at Volitans Software, so I guess I need to let him know.


Disk Drill appears to have the same problem.


Not sure what Drive Genius 3 is seeing, just shows "verified".


DriveDx appears to have no problem reading the same 24 attributes that TTP is able to, applicable to the Glyph drives.


Disk Utility doesn't even verify S.M.A.R.T. status on those drives.

Feb 19, 2016 10:10 AM in response to WZZZ

Bottom line, the only non-root owned items in my /usr/local are those that are brew or brew related. Those are owned by my admin user. Since they are only brew or brew related, like smartmontools, what's the security risk? How could that be used as an attack vector? Note: I run standard and use the admin account solely for authenticating--almost never logged into it, except when needing to sudo su. (And, as I said, there was no problem updating ClamXav there.)

Feb 20, 2016 2:50 AM in response to WZZZ

I was afraid I would not be able to explain this properly. Yes, everything is set up properly now because you installed ClamXav after HomeBrew, so the installer corrected the permissions on /usr/local itself. The problem will arrive when you attempt to update HomeBrew as it doesn't like /usr/local to be set to drwxr-xr-x root:wheel. When you go to the troubleshooting page I linked to above it tells you to run sudo chown -R $(whoami) /usr/local which modifies everything in /usr/local to be owned by the person executing the command, including everything in clamXav. But the signature database in /usr/local/clamXav/share/clamav and /usr/local/clamXav/etc/freshclam.conf need to be owned by the _clamav user & group in order to be used and updated.


The security problem is that with /usr/local owned by "$(whoami)" that leaves all third party software open to be modified by the owner. So a malware developer could easily substitute a fake component of ClamXav or other 3rd party software (including brew) for malicious purposes.

This thread has been closed by the system or the community team. You may vote for any posts you find helpful, or search the Community for additional answers.

All my browsers crash constantly! Need help to keep my sanity

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple Account.