I've seen this ever since Safari 8 on OS X 10.9.5, OS X 10.10.x all versions with Safari 8 and sadly in Safari 9 on all El Capitan betas to date, too. The Safari memory leak in my case is severe and Safari has to be completely quit & restarted often. It only seems to happen if you tend to have a few windows open a lot, which you "reuse"; but overall, Safari just grows and grows (by many GB).
Suggestions about "putting in more memory" are absurd. I've a 16GB Macbook Pro laptop which is the maximum configuration of soldered-on ("pro" my rear-end!) memory which Apple provide. It simply isn't possible to add more. Memory pressure and slowdown tend to get critical when Safari exceeds 10GB. I did once persist to the point where it was using over 13GB. When restarted with all tabs manually revisited to ensure all pages are loaded, it'll go back to about 2.5Gb. A leak of that size is utterly indefensible.
This is a stark change in behaviour from Safari 7, which behaved basically fine in this regard - yet there are surprisingly few reports of it online. It isn't a subtle problem and Safari 8 has been around for ages. Others would have noticed, yet few report it.
I see it on my 10.9.5 machine, 10.10 home laptop, 10.11 test laptop and even, more recently, a 10.10 laptop at work. My conclusion is that this must be Safari screwing up when particular bookmark, cookie, cache and/or other data is present and this data must be part of the stuff it shares over iCloud - otherwise I would not have expected my independently clean-installed-by-IT-vendor work laptop to exhibit exactly the same behaviour.
Bottom line is that this seems to be a user data thing. Taking a deep breath and doing a complete Safari reset - ditching your iCloud bookmarks, emptying everything from every Safari instance on the iCloud account, deleting ~/Library/Safari and so-on - might work according to the Developer Forums. But as ever with Apple since roughly OS X 10.7, its a heisenbuggy mess and no amount of psuedorandom chicken slaying will be guaranteed to fix your issue.
Closed tab stray processes might just be down to a "bad extension", but that's no excuse - extensions are under Safari control, and a bad extension should never be able to break the browser. It's just JavaScript code executing completely under the browser's oversight. Still, we know that Safari must have very poor code for extension support given the problematic history, so that's always worth investigating if you haven't already.
That other answer isn't good because you should not shut down your computer, and it is very unlikely that malware has anything to do with not being able to shut down an application. Do this
Type sudo killall Google\ Chrome on the Terminal.
If this does not work, do this:
pgrep -x "Google Chrome"
You will see a number, then type kill -9 numberhere where numberhere is the number that the pgrep command returned.
And to instatly delete the app, no matter if it is open or not, do:
sudo rm -rf /Applications/Google\ Chrome.app
Then type your password.
The reason you get a permission denied error is because you need root access do to this, just use sudo on the terminal for this.
Best Answer
OS X uses a process launching system called launchd which consolidates functions provided by Init scripts, crontab and more in *nix systems (see the Wikipedia article for a high level overview, and Apple’s Developer docs on launch daemons and agents for details). One of the abilities of launchd is to keep a process it launched alive, if so defined by its configuration file – in that case, the process will relaunch whenever it is terminated. Your problem with a process apparently persisting across reboots and manual termination sounds very much like a case of launchd initiated process with a
keepAlivekey.launchd configuration files are in plist format and found in
~/Library/LaunchAgents– agents for the current user account only/Library/LaunchAgentsand/Library/LaunchDaemons– agents and daemons for all user accounts/System/Library/LaunchAgentsand/System/Library/LaunchDaemons– system level agents and daemonsand are usually named in reverse domain notation (
tld.domain.process.plist). Depending if the user account ofserveris yours or not (can’t say, as you have blanked it), you should look in one of the first two locations above for a likely plist (if you have Xcode installed, you can QuickLook them easily). If found, yourserveris indeed controlled by launchd. The correct procedure to stop it is to remove it from launchd’s process list throughwhich will unload and stop the process (note you omit the
plistsuffix).There is also a GUI for handling launchd files, Peter Borg’s Lingon (make sure to get “Lingon”, not “Lingon 3”, which is a dumbed down version safe for vanilla use), which might be more convenient than manually rooting through the file locations.