The Crashers for Copies (or Even Cash!) Thread

Lo
Lo_B
Posts: 15
Joined: Mon Sep 12, 2011 11:29 am
Platform: Mac + Linux
Location: France (Provence).

Thu Apr 18, 2013 4:53 pm Post

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
Lo_B
Posts: 15
Joined: Mon Sep 12, 2011 11:29 am
Platform: Mac + Linux
Location: France (Provence).

Sat May 18, 2013 2:27 pm Post

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

Thank you in advance,

Loïc

User avatar
AmberV
Posts: 20612
Joined: Sun Jun 18, 2006 4:30 am
Platform: Mac + Linux
Location: Santiago de Compostela, Galiza
Contact:

Tue Aug 13, 2013 1:12 am Post

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.
.:.
Ioa Petra'ka
“Whole sight, or all the rest is desolation.” —John Fowles

js
jstovell
Posts: 22
Joined: Mon Apr 15, 2013 12:56 am
Platform: Mac

Wed Jan 15, 2014 7:45 pm Post

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.

User avatar
KB
Site Admin
Posts: 19190
Joined: Tue Jun 13, 2006 11:23 pm
Platform: Mac
Location: Truro, Cornwall
Contact:

Tue Jan 21, 2014 11:40 am Post

jstovell wrote: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...
"You can't waltz in here, use my toaster, and start spouting universal truths without qualification."

js
jstovell
Posts: 22
Joined: Mon Apr 15, 2013 12:56 am
Platform: Mac

Tue Jan 28, 2014 4:37 pm Post

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.)

User avatar
KB
Site Admin
Posts: 19190
Joined: Tue Jun 13, 2006 11:23 pm
Platform: Mac
Location: Truro, Cornwall
Contact:

Tue Jan 28, 2014 5:09 pm Post

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.
"You can't waltz in here, use my toaster, and start spouting universal truths without qualification."

sp
spankybus
Posts: 14
Joined: Mon Mar 04, 2013 12:30 am
Platform: Mac + Windows

Tue Feb 18, 2014 2:25 pm Post

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.

User avatar
KB
Site Admin
Posts: 19190
Joined: Tue Jun 13, 2006 11:23 pm
Platform: Mac
Location: Truro, Cornwall
Contact:

Tue Feb 18, 2014 2:31 pm Post

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
"You can't waltz in here, use my toaster, and start spouting universal truths without qualification."

gi
gianetto
Posts: 1
Joined: Mon Mar 10, 2014 4:39 pm
Platform: Mac

Mon Mar 10, 2014 4:54 pm Post

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
Attachments
Scrivener PDF crash debug.txt
debug text from scrivener
(88.56 KiB) Downloaded 23 times
5Sanford(clust1).pdf
PDF file that causes scrivener to always crash on zoom
(71.61 KiB) Downloaded 25 times

User avatar
KB
Site Admin
Posts: 19190
Joined: Tue Jun 13, 2006 11:23 pm
Platform: Mac
Location: Truro, Cornwall
Contact:

Tue Mar 11, 2014 10:57 am Post

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
"You can't waltz in here, use my toaster, and start spouting universal truths without qualification."

js
jstovell
Posts: 22
Joined: Mon Apr 15, 2013 12:56 am
Platform: Mac

Sat Sep 26, 2015 7:36 am Post

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... ]

User avatar
KB
Site Admin
Posts: 19190
Joined: Tue Jun 13, 2006 11:23 pm
Platform: Mac
Location: Truro, Cornwall
Contact:

Sat Sep 26, 2015 6:00 pm Post

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
"You can't waltz in here, use my toaster, and start spouting universal truths without qualification."

js
jstovell
Posts: 22
Joined: Mon Apr 15, 2013 12:56 am
Platform: Mac

Sat Sep 26, 2015 8:09 pm Post

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.

User avatar
KB
Site Admin
Posts: 19190
Joined: Tue Jun 13, 2006 11:23 pm
Platform: Mac
Location: Truro, Cornwall
Contact:

Sat Sep 26, 2015 8:21 pm Post

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
"You can't waltz in here, use my toaster, and start spouting universal truths without qualification."