Infinite frozen sync loop

I have a project set to sync with an external folder, left with the new default setting to automatically sync on close.

Running the sync, Scrivener freezes on 8 of 122 and throws this console error:
Scrivener[30839] -[NSWindowAuxiliary mainDocument]: unrecognized selector sent to instance 0x14f02810

I can hit esc to cancel the sync and continue on my merry way, but I tried repeatedly to sync and got this error. Then I figured I’d close the project and reopen to see if it fixed it–but the sync tries to run automatically on close and gets stuck. Hitting esc gets rid of the sync, but it also stops the project closing (and ultimately keeps you from quitting Scrivener except by a force quit).

Since there’s no way to change the sync settings without running the sync, it’s a bit of a loop. I ended up deleting the sync folder (moving it would’ve worked, but it was just a test sync) so I could close without force quitting.

I’ve gotten this a couple times, but not every time, so I’ll work on narrowing down the factors and report back. My last one happened when I opened the project, edited a file, then closed and it ran the automatic sync–it hung (the sync, not the program entirely), and spat out this:

2/14/11 12:35:48 PM Scrivener[30839] -[NSWindowAuxiliary mainDocument]: unrecognized selector sent to instance 0x14f02810
2/14/11 12:35:48 PM Scrivener[30839] HIToolbox: ignoring exception ‘-[NSWindowAuxiliary mainDocument]: unrecognized selector sent to instance 0x14f02810’ that raised inside Carbon event dispatch
(
0 CoreFoundation 0x92c296ba __raiseError + 410
1 libobjc.A.dylib 0x983f5509 objc_exception_throw + 56
2 CoreFoundation 0x92c7690b -[NSObject(NSObject) doesNotRecognizeSelector:] + 187
3 CoreFoundation 0x92bcfc36 forwarding + 950
4 CoreFoundation 0x92bcf802 _CF_forwarding_prep_0 + 50
5 Scrivener 0x001b0988 -[SCRArbitraryCollectionsTableController updateTable:] + 54
6 Foundation 0x9559c4df _nsnote_callback + 176
7 CoreFoundation 0x92bb0793 __CFXNotificationPost + 947
8 CoreFoundation 0x92bb019a _CFXNotificationPostNotification + 186
9 Foundation 0x95591384 -[NSNotificationCenter postNotificationName:object:userInfo:] + 128
10 Scrivener 0x00010954 -[SCRMainDocument takeSnapshotOfBinderDocument:snapshotText:snapshotTitle:playShutterSound:] + 752
11 Scrivener 0x001fab93 -[SCRFolderSyncSheetController syncDocInfo:index:isDraftItem:onlyIfInContainedInCollectionBinderDocuments:changedBinderDocument:] + 2783
12 Scrivener 0x001f90a1 -[SCRFolderSyncSheetController syncProjectWithFolder] + 3726
13 Scrivener 0x001f7cae -[SCRFolderSyncSheetController syncProjectWithFolderImmediatelyAndClose] + 379
14 Scrivener 0x000b292f -[SCRMainDocument(ImportExport) checkExternalSyncFolderNeedsUpdating] + 349
15 Scrivener 0x00014c05 -[SCRMainDocument cleanUpProjectBeforeClose] + 526
16 Scrivener 0x0003a957 -[SCRApplication terminate:] + 92
17 AppKit 0x949ffc46 -[NSApplication sendAction:to:from:] + 112
18 AppKit 0x949ffaf9 -[NSMenuItem _corePerformAction] + 435
19 AppKit 0x949ff7eb -[NSCarbonMenuImpl performActionWithHighlightingForItemAtIndex:] + 174
20 AppKit 0x949ff6da -[NSMenu performActionForItemAtIndex:] + 65
21 AppKit 0x949ff68d -[NSMenu _internalPerformActionForItemAtIndex:] + 50
22 AppKit 0x949ff5f3 -[NSMenuItem _internalPerformActionThroughMenuIfPossible] + 97
23 AppKit 0x949ff537 -[NSCarbonMenuImpl _carbonCommandProcessEvent:handlerCallRef:] + 336
24 AppKit 0x949f3c61 NSSLMMenuEventHandler + 404
25 HIToolbox 0x98618f2f _ZL23DispatchEventToHandlersP14EventTargetRecP14OpaqueEventRefP14HandlerCallRec + 1567
26 HIToolbox 0x986181f6 _ZL30SendEventToEventTargetInternalP14OpaqueEventRefP20OpaqueEventTargetRefP14HandlerCallRec + 411
27 HIToolbox 0x9863a9bb SendEventToEventTarget + 52
28 HIToolbox 0x98666fa7 _ZL18SendHICommandEventmPK9HICommandmmhPKvP20OpaqueEventTargetRefS5_PP14OpaqueEventRef + 448
29 HIToolbox 0x9868bd1c SendMenuCommandWithContextAndModifiers + 66
30 HIToolbox 0x9868bcd1 SendMenuItemSelectedEvent + 121
31 HIToolbox 0x9868bbda ZL19FinishMenuSelectionP13SelectionDataP10MenuResultS2 + 152
32 HIToolbox 0x9865b2e4 _ZL14MenuSelectCoreP8MenuData5PointdmPP13OpaqueMenuRefPt + 454
33 HIToolbox 0x9865aa56 _HandleMenuSelection2 + 465
34 HIToolbox 0x9865a874 _HandleMenuSelection + 53
35 AppKit 0x949ed1a2 _NSHandleCarbonMenuEvent + 285
36 AppKit 0x949c1d3e _DPSNextEvent + 2304
37 AppKit 0x949c0fce -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 156
38 AppKit 0x94983247 -[NSApplication run] + 821
39 AppKit 0x9497b2d9 NSApplicationMain + 574
40 Scrivener 0x00003289 _start + 208
41 Scrivener 0x000031b8 start + 40
42 ??? 0x00000002 0x0 + 2
)

(This is on the 2.0.45 beta.)

What are your sync settings? I just tried a quick test with 192 files and it ran without error. This was from a new test project though, so there might be something beyond settings that is impacting this. You aren’t the only one seeing it though, I just got word of it right before reading it. Here are the settings I ran with:

I tried some automatic syncs as well in both directions.

Yeah, I’m not getting it every time, but I just got it a bunch of times in succession. My settings are exactly the same except that I’m additionally only syncing the contents of a collection. There are five items in the collection, only one of which is actually in the Draft folder (ergo the only one that really would be syncing). I also have been syncing to a folder on Dropbox, so it’s possible that’s affecting things, although usually I have no issues with that and Dropbox hasn’t been actively syncing when I run the sync from Scrivener.

I got this new error when I tried to go in (on a fresh load of the project) and change the auto-sync settings:
Scrivener[32722] <SCRMainDocument: 0x1c94400> error: -setHasChanges: was called after the final save was performed. Observers should listen out for SCRMainDocumentWillPerformLastSaveBeforeCloseNotification for performing last-minute saves.

It ran the sync almost all the way but stopped at the end (122 of 122 but frozen). Escaping out worked but it then didn’t save the setting to not autosync anymore. Tried again (without closing) and it was a repeat of the problem.

And to clarify, I’m not even getting this same problem every time with this exact same project.

I wonder if this is related to the other problem you are seeing - the one where the “Changes were made - save?” dialogue appears.

What you experiencing is undoubtedly a memory bug. Scrivener’s main project class is called SCRMainDocument, and other objects call on it by calling -mainDocument. NSWindowAuxillary is an internal Apple class and never calls on -mainDocument. But when a memory bug occurs, you get odd classes calling on methods they shouldn’t do, because the original object has been destroyed from memory and a completely different object has since taken its place in the same memory space. So at that point, Scrivener expects one object to be there, asks it to do something, but it turns out to be another object that can’t do that thing, and everything goes bonkers. (And after errors like this, it is possible that you could see the standard “save” dialogue box, because all bets are off.)

The big question: On each time you saw this happen, had you closed a project beforehand? This looks to be related to one of the main outstanding bugs in 2.0 that I have been unable to track down, so any help you can get helping me reproduce this would be really, really appreciated.

Thanks!

All the best,
Keith

I have seen the save changes dialogues in 2.0.4, actually, without any crashing or hangs. When I was testing this bug yesterday, I noticed that when sync is enabled in a project and it has auto turned on, these have a tendency to come up after the sync completes. It’s like changes that the sync had to make in the project are made after the auto-save code shuts down or something.

I still can’t reproduce it, so any step-by-step instructions you can provide so that I can see it would be great.
Thanks!

Again, just for the save changes sheet; not the crasher. This seems to do the trick:

  1. New blank project with a couple of files with text in them in the draft; nothing in research
  2. Set project to Exclude from Automatic Backups
  3. Hook project up with a sync folder; default settings all around; folder saved into same location as .scriv file
  4. Edit one of the files so there is a discrepancy between the project and external folder
  5. Close the project

Sync interface will run; project starts to shut down; you get a “Would you like to save…” sheet. The key ingredient here is Exclude from Automatic Backups. If the project goes through the normal shutdown sequence with backups, it never complains.

I should also state that I haven’t noticed anything going sour or missing if I opt to not save changes. I suspect this sheet really doesn’t do anything at all. I set up two identical projects with identical parameters and triggered the bug identically, choosing to save in one and not save in the other and all of the key files were identical save for window position in ui.plist.

You can also get it by adjusting meta-data–if you add a label to one of the documents that’s syncing, it will now prompt the save dialogue.

Here’s another scenario:

  1. New blank project
  2. Set project to Exclude from Automatic Backups
  3. Create a new collection containing the default file in the Draft (with or without text)
  4. Set up with a sync folder, leaving default settings but checking the box to sync only the new collection
  5. Run the sync
  6. Close

The save dialogue pops up after it runs the auto sync.

In any scenario, whether you choose “save” or “don’t save,” after you’ve closed the project, quit Scrivener, and restarted, when you open that project and then close it without doing anything in the project, you get the dialogue.

I’ll add to this that I haven’t gotten any console messages all morning, and I’m quitting Scrivener and restarting like mad, so I think it’s not related to the other bug. Probably.

Also that you can run the sync in the session manually, then close without changing anything. In theory then your external folder should be in sync already with the project, but under the appropriate magical conditions it will still give you the save dialogue.

Back on the error messages here–bah, unfortunately I can’t be 100% certain but I’m going to say that it’s very, very likely, although how long before this I had closed the project I don’t know. I tend to leave projects open unless I know I’m going to be switching computers. My “test” project on each computer doesn’t usually move, so it stays open for long stretches at a time, and that’s the project I got these errors on. It’s almost certain that I had some other project open that got closed before I did this, and then in the course of getting these errors I closed and reopened this test project.

The <SCRMainDocument: 0x1c94400> error came after I had to force quit Scrivener, but I may have closed and reopened the same testing project between restarting Scrivener and getting this error; there’s about a half hour in between the two console reports.

Sorry I’m unhelpful about that. I know I’ve gotten the memory leak crash several times, and twice recently, so if I can just pay attention…I’ll let you know if I figure something out.

Great, thanks for the info, added to the list (I haven’t had time to test it yet though as I am deep in debugging land on a crasher). And any more information you can find on your crasher would be much appreciated. It may take a bit of effort to figure out the trigger given that it’s a memory bug…

Thanks!
Keith

I’ll be working on it. Started trying to keep notes on what I’m doing in projects when, maybe I’ll actually develop some memory cells again. We’ll see. I did want to say though that none of the errors above resulted in a crash, I think I was unclear on that. The loop problem didn’t crash the program, but it made me have to either move/delete the external sync folder or do a force quit on Scrivener. The sync itself hung, but after I escaped from that the program continued fine and dandy.

However I know I’ve gotten the memory crash a few times (er, sent you some reports recently), so it’s lurking there and it’s galling me that I can’t figure out what I’m doing to cause it. It’s becoming personal now. :imp:

Thanks for sending them. I go through the crash reports in batches and look at their characteristics, and have abandoned trying to reply to every one, at least until I can get them down to fewer than ten a day, which is what I’m receiving now. I’m hoping the one I’m working on now, and the one you have discovered, will cover the majority of the crashes people are experiencing.