The Crashers for Copies (or Even Cash!) Thread

[Lo_B]

Thanks. Happy to know the bug is already corrected. I’ll just wait then the new update to do the find and replace in my project…
Regards,
Loïc

[Lo_B]

I have not found that beta version : can you tell me where to find it ?

Thank you in advance,

Loïc

[AmberV]

The latest public beta will always be posted to this thread. You can subscribe to that thread to stay notified of updates, and the first page will have the release notes and installation instructions.

[jstovell]

I may have found a new crashing bug. It is somewhat similar to this one, in that both involve the dictionary popup (⌃⌘D), but there are some notable differences.

The steps that consistently reproduce the crash on my machine:

1. Select a single document in the Binder that contains absolutely no content whatsoever.
2. Make sure the Editor has focus (i.e. so that the text insertion cursor can be seen flashing in the empty Editor).
3. Wiggle the mouse so that the mouse cursor can be seen, but keep it floating over the text entry area in the Editor. The mouse cursor should be showing its version of a text insertion cursor.
4. Press ⌃⌘D or use the trackpad gesture or whatever to summon the dictionary popup.

I have an idea about the cause. Pressing ⌃⌘D normally tries first to look up whatever word is under the mouse cursor. If that fails, it then goes through a series of fallbacks trying to find a word. But in this case, there are no words in the document at all, so nothing is ever found. For whatever reason, Scrivener is not handling this gracefully and instead crashes unceremoniously.

I am running Scrivener 2.5 (25239) on OS X 10.9.1. My computer is a MacBook Pro 15" (Mid-2010). I sent in one of my crash logs (they are all the same apart from the hexadecimal dead beef values) via the built-in crash reporter.

[KB]

I may have found a new crashing bug. It is somewhat similar to this one, in that both involve the dictionary popup (⌃⌘D), but there are some notable differences.

This is unfortunately a known bug in OS X - you can see the same crash in Nisus Writer. The Ctrl-Cmd-D dictionary is all controlled by OS X code - there isn't a line of code that touches this in Scrivener itself. The problem is that, for some obscure reason, a subclassed NSTextView will crash in this circumstance. Nisus and Scrivener both use custom, subclassed NSTextViews (NSTextView being the standard text editor on the Mac), which is why they crash but TextEdit (which uses a vanilla NSTextView) doesn't.

I reported this to Apple in December 2012 and it is in their system as bug ID #12776187. I provided them with sample code that reproduces the crash. Their response was, "Please send a crash log so we can investigate." I pointed out to them that they didn't really need one since I had provided them with everything they needed to reproduce the crash for themselves, but sent them a crash log anyway. That was the last I heard from them - the bug report is still listed as "Open" on Apple's system. Reporting bugs to Apple can be a hugely frustrating experience, as they often ask you for information you've already sent and then bugs go unfixed anyway...

[jstovell]

Bleh. That's annoying. Oh well, thanks anyway, Keith. I guess I'll stick with the "So, don't do that!" workaround until Apple gets around to fixing this.

(Aside: One would think that with coffers so full and self-professed fanatical devotion to perfection, Apple would hire more coders to form a larger bug-hunting division.)

[KB]

Doubly annoying because the dictionary popover is a black box - there's no access to it in publicly-declared coding methods and all hidden to non-Apple coders, so there isn't even a way for me to work around the bug in my own code, which is usually possible.

[spankybus]

Prolly nothing special, but here it is:

Hello,

Scrivener crashed on me. The following is a short description of what I was doing when Scrivener crashed:

1) ...Machine was idle

2) ...Machine went dormant

3) ...this process happened several times (wake, sleep, wake, sleep) over the course of the morning. Note that scrivener was actively running a project during this time and it was 'live' in so far as the icon on the task bar had the little dot underneath it.

4) ...Eventually went to use scrivener after waking up the machine. The little dot was now missing from below the icon. When i launched scriv I got this crash. This is the second time.

Note other applications still in memory (little dot under their icon on the menu bar) include photoshop (cs6), Mail, Google Chrome (it did have pages up) an adobe acrobat updater and finder, as always.

Using latest version of Maverick's (Software OS X 10.9.1 (13B42))

Crash Report:

Hardware:

Hardware Overview:

Model Name: MacBook Pro
Model Identifier: MacBookPro10,1
Processor Name: Intel Core i7
Processor Speed: 2.3 GHz
Number of Processors: 1
Total Number of Cores: 4
L2 Cache (per Core): 256 KB
L3 Cache: 6 MB
Memory: 8 GB
Boot ROM Version: MBP101.00EE.B02
SMC Version (system): 2.3f36



Crash report sent by version: 2.5 (25239)

Process: Scrivener [19733]
Path: /Applications/Scrivener.app/Contents/MacOS/Scrivener
Identifier: com.literatureandlatte.scrivener2
Version: 2.5 (2.5)
Code Type: X86 (Native)
Parent Process: launchd [282]
Responsible: Scrivener [19733]
User ID: 501

Date/Time: 2014-02-10 21:51:00.405 -0500
OS Version: Mac OS X 10.9.1 (13B42)
Report Version: 11
Anonymous UUID: E961045E-4CFC-D07E-1F24-B1806468FC87

Sleep/Wake UUID: 63FB4D27-A279-4D1B-8E82-E27E265DAAC5

Crashed Thread: 0 Dispatch queue: com.apple.main-thread

.....

Will send in the full crash report via standard bug reporting pop-up.
---


Never had this happen before. If you require any additional info, please let me know. Will fire off the crash report proper as well. FYI, the active project was undamaged.

[KB]

Thanks. The crash report you sent suggests that the crash occurred when trying to show the tooltip that appears when you hover the mouse over the word count in the editor footer bar. If you try to show this tooltip again, does it crash again? Tooltips can be a little temperamental on OS X occasionally, but they shouldn't cause a crash, but unfortunately the crash log doesn't give many other clues.

All the best,
Keith

[gianetto]

Scrivener has been crashing on me constantly with reference PDFs I've been using lately

The steps are simple:
1) Create a new scrivener project
2) Drag one of my reference pdfs from the finder to the scrivener research folder
3) Click on the pdf in the research folder and zoom in with the command +....crashes at around 3-5 zooms.

I've attached the pdf in this post along with the debug text.
-Dave

[KB]

Thanks for this. I can reproduce the crash, although it seems to be coming deep from within OS X code rather than from within Scrivener. However, the same PDF isn't crashing in Preview, Skim or DevonThink, which use the same PDF viewer as Scrivener, so there must be some extra trigger. It is going to take some extra investigation to get to the bottom of this, especially seeing as the crash log is indicating nothing in Scrivener's code, so I have put this on my list for investigation and made a not of your post. I'll get back to you when I have something to report.
Thanks and all the best,
Keith

[jstovell]

Hello,

Scrivener crashed on me. The following is a short description of what I was doing when Scrivener crashed:

1) Toggling between page view and normal view (Option-Shift-Command-P).

This has happened numerous times now, as you can probably tell by the number of crash reports I have submitted in the past hour or so via the automatic crash reporter.

The crash happens with different Scrivener projects, different documents selected in the editor within any given project, and regardless whether I use the toolbar button, keyboard shortcut, or menu item to toggle between views.

It may be helpful to note that this crash happens on the first or second time I toggle views while showing documents in Scrivenings mode, but I can toggle views several times before the crash occurs if I am using single-document mode.

It may also be helpful to note that if I toggle the view several times, sometimes text will stop rendering in the editor on the last such switch before the crash occurs. In these cases, everything will start out looking fine. Then I toggle from page view to normal view (or vice versa) and suddenly all the text disappears from the editor, so that I am left staring at an apparently blank page. This will stay the case even if I bring up an entirely different document in the editor. Once this blank editor issue appears, the very next time I try to toggle between page view and normal view, a crash always occurs.

My suspicion is that there is some unpleasant memory leak happening with the text rendering when changing views in the editor. I've submitted a series of crash logs via Scrivener's crash reporter so that you can examine them. but here is a typical example:

Hardware:

Hardware Overview:

Model Name: MacBook Air
Model Identifier: MacBookAir5,2
Processor Name: Intel Core i5
Processor Speed: 1.8 GHz
Number of Processors: 1
Total Number of Cores: 2
L2 Cache (per Core): 256 KB
L3 Cache: 3 MB
Memory: 4 GB
Boot ROM Version: MBA51.00EF.B03
SMC Version (system): 2.5f9



Crash report sent by version: 2.70 (26106)

Process: Scrivener [21722]
Path: /Applications/Scrivener.app/Contents/MacOS/Scrivener
Identifier: com.literatureandlatte.scrivener2
Version: 2.7 (2.70)
Code Type: X86 (Native)
Parent Process: ??? [1]
Responsible: Scrivener [21722]
User ID: 501

Date/Time: 2015-09-26 01:17:10.936 -0600
OS Version: Mac OS X 10.11.1 (15B17c)
Report Version: 11
Anonymous UUID: C6D973F4-FE25-313E-A397-040932AF2E0B

Sleep/Wake UUID: B58641F3-18B6-457F-850C-A53D7C7BBAD9

Time Awake Since Boot: 23000 seconds

System Integrity Protection: disabled

Crashed Thread: 0 Dispatch queue: com.apple.main-thread

Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000020
Exception Note: EXC_CORPSE_NOTIFY

VM Regions Near 0x20:
-->
__TEXT 0000000000001000-0000000000369000 [ 3488K] r-x/rwx SM=COW /Applications/Scrivener.app/Contents/MacOS/Scrivener

Application Specific Information:
objc_msgSend() selector name: hash


Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
[blah blah blah... ]

[KB]

Hi,

Thanks for the bug report. Unfortunately, this is a known bug in El Capitan that I have submitted to Apple. If is triggered in the following situation:

- It only affects 32-bit apps (Scrivener 2.x is 32-bit).
- It occurs when a 32-bit app tries to access standard system/user fonts.
- It only occurs if the user account has custom font settings in the global preferences file (e.g. an "NSFont" entry in the .GlobalPreferences.plist file).

We have instructions on how to clear the global preferences file in order to stop the crashes here:

https://scrivener.tenderapp.com/help/kb ... -os-x-1011

I finally tracked the exact causes of this bug today and reproduced it in a simple test application that I have sent to Apple along with everything they need to reproduce it, so fingers crossed they fix it quickly, since the 64-bit version of Scrivener won't be ready until next year some time.

All the best,
Keith

[jstovell]

Thanks, Keith. Creating another admin user and then wiping out my entire .GlobalPreferences.plist as those instructions suggested seemed a bit overkill to me (.GlobalPreferences.plist also tracks favourite Finder tags, user defined text replacements, mouse behaviour preferences, etc., etc.). But I found that simply running the following command in Terminal and then logging out and back in again did the job nicely.

Code: Select all

defaults delete .GlobalPreferences NSFont

No more crashes now. You might want to update that knowledge base article to suggest that users try that first before moving on to the more draconian method.

[KB]

Thanks for that! I wasn't sure if that would work on its own or if the NSFixedPitchFont and NSSystemFont settings might cause problems too, but that's great that it worked. I've updated our Knowledge Base article to suggest that as the first thing to try before deleting the .GlobalPreferences.plist file entirely. Thanks again!

All the best,
Keith