Q: Pages 5.6.2 Uses 100% CPU for exactly 30 minutes, then errors
I'm using a fairly old Mac Pro Early 2008 but running the latest OSX 10.11.5, and the latest version of Pages, 5.6.2 (2573). My boot disk is a 256GB SSD with 38.52GB free. I've gone as low as 15GB free and still been able to use the system, but I also understand that sometimes apps and OSX want more free space than 10%. I'm at close to 15% free.
Up until yesterday, all was well. I didn't have any trouble with Pages. But then yesterday I closed a document, then opened another, then attempted to duplicate it. That's when I got the SBOD (Spinning Beachball of Death). I waited a few minutes, but it just hung. So I killed it and opened it again, with the same behavior. Open Pages, the menu bar populates, but no main window comes up, the process is using 100% of one of my 8 CPUs, and is considered Unresponsive by Force Quit Applications.
So I deleted Pages using AppZapper, then re-installed it using App Store. And the exact same thing happened, even after I manually deleted com.apple.iWork.Pages.plist from ~/Library/Containers/com.apple.iWork.Pages/Data/Library/Preferences/ in order to see if any lingering preferences were causing the problem. I did get the "Welcome to Pages" intro page, but when I hit "Continue" I got the SPOD again.
So before I went to bed, I wrote a small shell script to check the process and CPU usage every 30 seconds to see how long it used 100% of the CPU, and also tailed the system.log to see if anything got put in there that was interesting. And it did!
I started the Pages App at 10:39pm EDT on July 10, 2016. My logs show that at 11:09pm EDT, almost exactly 30 minutes later, the CPU utilization for the Pages process dropped to 0%. So that's kind of weird, makes me think of an obscure timeout somewhere in pages that just took a long time to reach. But why 30 minutes? I'm not using NFS or Samba for anything that I know of.
Then I checked the system.log and found these beauties, with timestamps that line up with the end of the 30 minute SBOD time, plus one that hit exactly 15 minutes after starting:
Jul 10 22:54:22 max Pages[4367]: IMKClient Stall detected, *please Report* your user scenario attaching a spindump (or sysdiagnose) that captures the problem - (imkxpc_uniqueClientIdentifierStringWithReply:) block performed very slowly (174.87 secs).
Jul 10 23:09:15 max Pages[4367]: *** Assertion failure #3: -[TSPArchiver updateMessageInfo:withArchiver:] TSPArchiver.mm:360 Message for object [TPArchivedLayoutState-30087] is larger than the 67108864 bytes size limit.
Jul 10 23:09:16 max Pages[4367]: *** Error: __71-[TSAViewStateSidecar writeViewStateObject:completionQueue:completion:]_block_invoke60 TSAViewStateSidecar.mm:145 Failed to write view state data with error: Error Domain=com.apple.iWork.TSPersistence Code=2 "Couldn't auto-save document." UserInfo={TSULocalizedErrorAlertTitle=Couldn't auto-save document., NSLocalizedRecoverySuggestion=Your most recent changes might be lost., TSULocalizedErrorAlertMessage=Your most recent changes might be lost., NSLocalizedDescription=Couldn't auto-save document.}
Ah HA! So there's something in Pages that is trying to send an object that is larger than the 64MB limit. But what? and to where? And why? What is TSPArchiver? And to where is Pages trying to auto-save which document?
So if anyone has an idea on how to fix this, that'd be awesome. I'd like to not have to wait 30 minutes to use Pages.
Posted on Jul 11, 2016 6:43 AM
