Sonoma Crash when Viewing Full Manuscript

Scrivener Scrivener for macOS
,
1

I have a novel manuscript project, that has been intermittently crashing to desktop when I go from a selected chapter folder to the entire manuscript.

It begins loading the manuscript into the main editor window, displays a loading animated circle for about five seconds, then crashes to desktop.

This behavior repeated several times upon reload, then I tried opening the same project on my M2 MacBook Air, instead of the M1 Mac Studio, and was able to successfully select the entire manuscript.

I then saved the project, reopened it on the Mac Studio and was able to select the full manuscript, at least once. I haven’t tried it again yet.

This instability has me more than a little freaked out as I have two books due to publishers within the next several weeks. One for beta readers and one for final release.

I’ve sent the entire crashlog to the support e-mail, but will copy a portion of it here as well. Happy to paste the entire thing if helpful.

Thanks in advance for any ideas why this is happening.

— snip —
------------------------------------- Translated Report (Full Report Below) -------------------------------------

Process:
Path:
Identifier: Version:
Code Type: Parent Process: User ID:

Scrivener [2003] /Applications/Scrivener.app/Contents/MacOS/Scrivener

com.literatureandlatte.scrivener3 3.3.3 (15931)

ARM-64 (Native) launchd [1]

501

Date/Time:
OS Version: Report Version: Anonymous UUID:

2023-10-01 14:07:17.9045 -0400 macOS 14.0 (23A344)

12

Time Awake Since Boot: 4900 seconds System Integrity Protection: enabled

Crashed Thread:

Exception Type: Exception Codes:

0 Dispatch queue: com.apple.main-thread

EXC_BREAKPOINT (SIGTRAP) 0x0000000000000001, 0x000000018a1d04b8

Termination Reason: Terminating Process:

Namespace SIGNAL, Code 5 Trace/BPT trap: 5 exc handler [2003]

Application Specific Backtrace 0: 0 CoreFoundation

4823DBA9-2480-E9BA-198C-C7A34AE6BDD2

0x00000001867908c0 __exceptionPreprocess + 176 0x0000000186289eb4 objc_exception_throw + 60

  1. 1 libobjc.A.dylib
  2. 2 CoreFoundation

exceptionWithName:reason:userInfo:] + 0
3 AppKit 0x0000000189f16f74 -[NSWindow(NSDisplayCycle) _updateStructuralRegionsOnNextDisplayCycle] + 1368
4 AppKit 0x000000018a5cc450 -[_NSTrackingAreaAKManager invalidateCursorRectsForView:] + 88
5 AppKit 0x000000018a5ceef0 -[_NSTrackingAreaAKViewHelper _viewDidChangeGeometryInWindow:] + 76
6 CoreFoundation 0x0000000186710780 CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER + 148
7 CoreFoundation 0x00000001867a49a8 ___CFXRegistrationPost_block_invoke + 88

  1. 8 CoreFoundation 0x00000001867a48f0 _CFXRegistrationPost + 440
  2. 9 CoreFoundation 0x00000001866df434 _CFXNotificationPost + 764

0x00000001867907b0 +[NSException

10 Foundation 0x00000001877d0c74 -[NSNotificationCenter postNotificationName:object:userInfo:] + 88

2

What version of Scrivener?

Just curious. With deadlines approaching, what was the compelling reason to upgrade to Sonoma so soon in its life cycle? *.0 versions normally should be avoided.

3

Did you have your Scrivener Project CLOSED on all other devices when it crashed on your Desktop?

I get it that this would be concerning. From my experience, however, with over 10 years using Scrivener – it really is one of, if not THE most stable program I use. Hopefully, when you get this figured out, you will be able to enjoy that too.

1 Like
4

3.3.3

As for why I upgraded to Sonoma, I’d have to say a combination of complacency and stupidity. sigh

I read the forums and Scrivener seemed to be fine with the exception of the dark mode issue. I waited until after 3.3.3, dropped then updated the Macs.

Generally I do avoid *.0 OS versions, and probably should have here as well. That said, this issue is likely not going to be addressed by a MacOS dot release. I think it’s likely something within Scrivener itself that will need to adjust to some quirk of Sonoma rather than the reverse.

5

@denisehtodd Yes, definitely closed all all devices. I’m manic about that having made that mistake once about four years ago.

I agree, Scrivener definitely has been extremely stable for me as well, wasn’t trying to imply otherwise and apologize if that’s how in seemed. I even mentioned that very thing in my direct e-mail to the support address. Still, it’s an issue I’m faced with now, so am hoping they can help me figure it out.

As additional context. This particular novel is about 230,000 words and, with around 50 chapter folders which each comprise 1-2 scenes each.

I’m thinking that something goes awry when Scrivener starts organizing all them together under the manuscript, which I do from time to time in order to facilitate a book-wide search and replace.

6

I feel your pain. Re this thread, I’ve fed everything back to support and downgraded back to Mac OS Ventura and Scrivener 3.3.1. while L&L resolve. I suspect, if possible, it might not be a bad idea to do the same. Like you, I’ve always relied on Scrivener and trusted in its stability; and so the experience of the last couple of days has been unnerving to say the least—even now, back on OS Ventura and 3.3.1, any second I’m expecting to see the app crash out!

Have a better one.

2 Likes
7

I know this anecdotal but my Scrivener 3.3.3 on macOS 13.6 is working (far as I can tell), perhaps best way to de-risk your issue with deadlines is to revert back to the previous macOS version but keep Scrivener at current version and only move back if needed. Apple provides instructions for how to do on their support pages (find via Google). Just a thought.

Edit: or if messing with your laptop a bit risky given deadlines, buy or rent another and put the older macOS on that and install Scrivener, to enable moving forward quickly.

8

Yeah…I have an old 2015 MacBook Pro that I think is running Monterey, so worst comes to worst, I can pull that out of mothballs, assuming it still works. I guess my procrastination at recycling it may pay off.

The crash I’m experiencing only occurs when I select the overall manuscript and happens about 50% of the time, so it’s incredibly nerve racking, but not job-ending.

As a testament to how stable Scrivener has been in the past, I’ve never needed to come to these forums for help, so am rather the newb. I haven’t seen any official Scrivener folks reply to this thread or even indicate that they’ve read it.

Is there something I’m supposed to do to get their attention, other than maybe tagging @AmberV who I saw working a different crash issue?

9

To contact the support team directly, please open a support ticket, here:

We do monitor the forums, but it’s very difficult to keep track of everything.

Over the last few days, a number of Sonoma-related crash reports have been trickling in. We haven’t yet identified the common denominator, much less determined whether the underlying cause is in our code or Apple’s. At this time, I would avoid installing Sonoma if possible.

Other than the now-fixed Big Sur issue, we don’t have any reports of crashing with other versions of Mac OS. Still, if you have a stable 3.3.1 installation and an imminent deadline, staying with the status quo is not a bad idea.

10

Argh, thanks. I need my writing machine to be 100% reliable, so I downgraded to Ventura… I had to create a bootable USB installer, erase the hard drive, and then restore from a backup. I guess I’ll wait a while longer before upgrading to Sonoma.

1 Like
11

Snap. I rely on Scrivener too much and was mid project. Lesson learned.

1 Like
12

@kewms Thanks for the clarification. I have submitted using the form, and received an acknowledgment e-mail, but there is no specific tracking number. I provided the crash log along with the steps that created the issue.

Are there any next steps I can do to help and is there any way to ensure this issue has been received/reviewed?

13

@kewms

Some additional info. I submitted a second crash report using the form in case having two helps troubleshoot.

Things have gotten a bit worse in that the crash now happens 100% of the time I try to select all chapters in the project by clicking on the manuscript item (under which all the chapter folders reside)

That said, I can click the chapter folders and select several of them without incident. Some place between 50 chapter folders and 60 is where the crash occurs even when using the shift-select method.

I wonder if there is some kind of memory leak as Scrivener is trying to load all those chapters and scenes into memory. I don’t know. It’s been 20+ years since I’ve coded so maybe memory leaks aren’t even a thing anymore. That said, I can reliably reproduce the error whenever “too many” chapter folders representing “too much” content is being brought into the main editing window.

Hope this helps!!

14

If you received the acknowledgement auto-response, then our ticket system has received your email and you are able to receive our responses. Email misfires are the biggest reason for lost tickets, so if you’re past that hurdle someone should get back to you in a day or so.

It probably won’t be me, as I’m taking some time off over the next few days.

15

Would it be possible to run some tests against this sample project I’ve created? It’s very simple (a chopped up Project Gutenberg book with nothing fancy going on, just text). I’ve duplicated the book three times, so there is now a total of 216 binder items in the Draft folder, holding ~475k words. I.e. well in excess of the scale you are working on.

:floppy_disk: Test project download (~2.2mb ZIP)

In my testing:

  • Switching the Draft folder to Scrivenings mode takes about second or to assemble the 475,539 word session. There is no stuttering, typing lag or any indications of if struggling whatsoever.
  • RAM usage remains fairly consistent for me, and tidy considering the amount of text and user interface being juggled around. I don’t see a sudden spike that would explain a bad memory leak during Scrivenings session assembly. There may be some leaks (we’ve scrubbed most of them to my knowledge but you never know), but they are probably the sort that take a lot of very specific types of usage to notice. For instance if I close this project, Scrivener’s usage remains higher than on a clean launch without any projects open—but that’s to be expected given how modern memory management works, and is nothing to be concerned about when opening the project again consumes nearly exactly the same footprint as before.
  • Testing done on a baseline Mac Mini M2.

If this project causes similar instability for you, I’d have to think about what to try next, but the obvious next test step would be to create a quick user account on your Mac so you can throw this project into a clean environment with factory defaults across the board, no background software running, and see if goes away. That would at least narrow it down to something in your local context.

16

Hi @AmberV

Thanks for the reply. I am also working with Alex and the dev team so hopefully between both threads we can squash this bug for me and others.

I tested your sample project and there were no issues other than it loaded the entire document MUCH faster than it does with my project. No idea why, however, I have sent that project to Alex, so perhaps you could run a similar test on it from your end. He did an initial test but did so on Ventura so wasn’t able to reproduce the issue.

He’s also asked me to try a daily-test-build the devs just gave him, so I’ll give that a whirl as well.

Thanks again for the follow-up and please let me know what happens when you test my actual project on your Sonoma machine. If you need me to send you a separate copy of the project, please just shoot me an e-mail and I’ll be happy to do so.

2 Likes
17

Fingers crossed the test build works for you. The crash seems to be triggered in the following circumstances:

  1. Page view is being used.

  2. Page view is set be horizontally centred in the Settings (which is the default).

  3. The page view is zoomed (i.e. not using 100% zoom).

The test build tweaks a bit of code to do with zooming the page view. That worked in my tests on a project where I could reproduce the crash. We now just need to confirm with users that it works for them, as the actual fix is a bit odd (whereas the zoomed page size was previously rounded, in the new build it’s not). Odd, but not entirely without precedent - the text system is hugely fragile when it comes to scaling, and I have run into nasty and unexpected problems caused either by rounding or not rounding in the past.

All the best,
Keith

1 Like
18

Hi @KB

So far so good, but the crash was so intermittent that I’ll be sure to do more testing and let y’all know how it goes.

Couple follow up questions because I didn’t quite understand your points 1-3

  1. Page view? You mean the main editor view?
  2. Set horizontally? Where is that setting? You mentioned it being the default and I don’t remember ever changing it so it’s probably set that way
  3. Page view zoomed: Mine is set at 175%

So, for others that are not troubleshooting with the 16007 test build, would they be able to avoid the crash by changing that zoom back to 100%?

Much thanks for everyone’s efforts.

19

[quote=“rwross, post:18, topic:136519”]

  • Page view? You mean the main editor view?[/quote]

Page view in the editor view - where you have the editor set up to look like pages (View > Text Editing > Show Page View). Your crash log indicates that this was being used, and this seems to be a common factor.

Scrivener > Settings… under Appearance / Page View / Center pages.

Yes, or turning off “Center pages” in the settings mentioned above - at least these seem to be the triggers from my testing.

All the best,
Keith

20

UPDATE: Please try this build instead of the one provided earlier:

We found some other circumstances in with the earlier build could still crash.

Thanks and all the best,
Keith