This is the third day running that Scrivener has frozen on me since upgrading my Macbook Air to Yosemite.
Each time, the freeze happens when I stop typing and click in the binder refer to some other part of the project, or if I open another project and click in the binder to drill down to a particular scene.
Each time the Mac has been up and running for several hours, although I might only have been running Scrivener for 20 minutes. Two times out of the three I lost work (the first time 1500 words, the third time 400 words - particularly galling during NaNoWriMo. The second time I didn’t lose work because I had only just done a manual save.) Scrivener won’t restart at this point without a reboot.
AutoSave is set to 2 minutes (120 seconds) although it didn’t seem to have worked. (maybe I didn’t stop typing for 2 minutes, but given the way I work, that seems unlikely). My projects are stored on Dropbox, hence the longer delay over default - to save wifi & battery life.
This definitely seems to be related to Yosemite in some way, since under Mavericks I didn’t reboot my Macbook for weeks on end, and never had a single problem. & also it seems linked to how long the system has been up
Anyone else experiencing something similar?
I should add that I’m on Scrivener 2.6 (25479).
Is the problem only happening when you view PDF files? If so, refer to this article on what might be the cause and how it can be avoided: PDFs in Mac OS X 10.10 (Yosemite) cause editor to become stuck.
Nope. While there is a pdf in the second project, it doesn’t contain tables, and has not been opened or viewed during the session. The primary project does not contain any pdf files. Neither have any pdf files been viewed outside of Scrivener.
Okay, thanks for checking. Since time seems to be a component of the problem, one thing that comes to mind is a “memory leak”. Ideally this number should only bump up significantly when opening projects, it should also remain fairly stable over time for every project you open. Note it may increase and decrease when “doing stuff”, this is normal, particularly for some types of operations like loading a large-scale Scrivenings session or compiling (both of which require loading lots of text and potentially images). There isn’t a standard here, but you definitely shouldn’t see something like 800mb being used if you only have a couple of small-ish projects open. Normal operating size is around 20 to 100mb.
So keep an eye on Activity Monitor’s “Memory” tab, particularly that “Memory Pressure” graph. You can search for “Scrivener” and just leave it in the background, checking it periodically as you work through the day. If the number is steadily increasing as you work by an order of tens of megabytes or greater, it may be we have some code that isn’t being properly destroyed once it has been used.
Sorry to hear that. This is probably because you have the auto-save timer set for so long. Keep in mind that is an idle timer, not a repeating cycle. The default 2-sec setting means Scrivener will never auto-save until you pause typing for two seconds. With a 2-min idle timer, the only time Scrivener is saving is when you’ve stopped writing for a bit—and since you lost 400 to 1,500 words, it sounds likely that you don’t pause for that long very often during a writing session.
What I would strongly advise, until we figure this out: crank that back down to the default, and instead make it a habit to use the pause button on Dropbox. This will knock out the biggest battery drain in the procedure, the constant WiFi activity. Since you mention using a MacBook Air, the power drain associated with saving a few sentences of text now and then is going to be next to nothing as that whole system has no moving parts (whereas an older laptop might have to spin up a physical platter).
This way, when/if it crashes you will lose far less than entire days worth of work.
Two more things to do:
- Leave Console.app runnning and report any lines from Scrivener that you get from around the crash, and particularly after the crash, when it won’t restart.
- In Scrivener, visit the “General” preference tab, and enable Show internal error reports at the bottom. If at any point during your session you get a pop-up window alerting you to an exception having taken place, send it in using the reporting tool (paste this forum thread URL into the comments area so that I can easily find it).
Okay, that should get us a little more information on what is going on. Also send in any crash reports if you can, also referring to the forum URL so I can find them.
Thanks. I’ll do those things and see what happens.
The actions themselves don’t cause a problem - I can repeat what I did after a boot and it doesn’t hang. (I don’t think it actually crashes as such, it just goes into a not responding state, with the coloured ball spinning)
Yeah, understood. Some bugs can start quite a bit before they actually manifest as a hang or other difficulty, making them difficult to pin down to a particular sequence of actions taken directly prior to the bug happening. The internal error flag that I wrote of will help detect those kinds of problems that can otherwise be invisible.