Cocoa crashes in -[SCIContentView viewWillDraw]

153 views
Skip to first unread message

Chinh Nguyen

unread,
Aug 26, 2015, 11:41:20 AM8/26/15
to scintilla-interest
Ordinarily I would file a bug but I can't reproduce this bug so I'm putting this out there in case anyone else has seen this problem. I've had a few users report random crashes with our text editor that I can't explain. They seem to be limited to less than a handful of users out of thousands (over the last 2-3 years).

I'm currently using version 3.5.7 but this problem has existed since I first started using Scintilla a few years ago. Here are a couple of partial crash logs:

Date/Time:       2015-08-12 23:24:25.370 -0500
OS Version:      Mac OS X 10.9.5 (13F1096)
Report Version:  11
Anonymous UUID:  F5A824A6-7C82-96A3-C861-7D3B832C628C

Sleep/Wake UUID: D2F2CCD9-9FF3-4BFF-892C-7386D2871227

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

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: EXC_I386_GPFLT

Application Specific Information:
objc_msgSend() selector name: backend


Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libobjc.A.dylib                     0x00007fff92c9f097 objc_msgSend + 23
1   com.sun.Scintilla                   0x00000001103d3bbe -[SCIContentView viewWillDraw] + 266
2   com.apple.AppKit                    0x00007fff91c4bcf1 -[NSView(NSInternal) _sendViewWillDrawAndRecurse:] + 332
3   com.apple.AppKit                    0x00007fff91c4b98f -[NSView(NSLayerKitGlue) _layoutSublayersOfLayer:] + 147
4   com.apple.QuartzCore                0x00007fff8fcd2e51 -[CALayer layoutSublayers] + 214
5   com.apple.AppKit                    0x00007fff91c4b8eb _NSBackingLayerLayoutSublayers + 160
6   com.apple.QuartzCore                0x00007fff8fcd2a25 CA::Layer::layout_if_needed(CA::Transaction*) + 363
7   com.apple.AppKit                    0x00007fff91cd1e7e -[NSView _pullInTilesByDrawingAndAddingSubviews] + 83
8   com.apple.AppKit                    0x00007fff91cd1e12 -[NSView _pullInExtraTilesForOverdraw] + 87
9   com.apple.AppKit                    0x00007fff91cd1d7e -[NSView _doIdlePrefetch] + 59
10  com.apple.AppKit                    0x00007fff91d006ec -[_NSScrollingConcurrentMainThreadSynchronizer _doIdlePrefetch] + 88
11  com.apple.AppKit                    0x00007fff91cff287 -[_NSScrollingConcurrentMainThreadSynchronizer _synchronize:completionHandler:] + 48
12  com.apple.AppKit                    0x00007fff91cff20f __80-[_NSScrollingConcurrentMainThreadSynchronizer initWithSharedData:constantData:]_block_invoke + 140
13  libdispatch.dylib                   0x00007fff955ae28d _dispatch_client_callout + 8


Date/Time:       2015-08-01 18:51:49.939 -0400
OS Version:      Mac OS X 10.9.5 (13F1096)
Report Version:  11
Anonymous UUID:  F5A824A6-7C82-96A3-C861-7D3B832C628C

Sleep/Wake UUID: 044ACE84-7739-4219-A788-818BDF785BF0

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

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000000

VM Regions Near 0:
-->
    __TEXT                 0000000100000000-0000000100da1000 [ 13.6M] r-x/rwx SM=COW  /Applications/Stata/Stata.app/Contents/MacOS/Stata

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   com.sun.Scintilla                   0x000000010180d1e9 Scintilla::Editor::PositionAfterArea(Scintilla::PRectangle) const + 141
1   com.sun.Scintilla                   0x00000001017e8de2 Scintilla::ScintillaCocoa::WillDraw(CGRect) + 42
2   com.sun.Scintilla                   0x00000001017eac05 -[SCIContentView viewWillDraw] + 309
3   com.apple.AppKit                    0x00007fff8a25acf1 -[NSView(NSInternal) _sendViewWillDrawAndRecurse:] + 332
4   com.apple.AppKit                    0x00007fff8a25a98f -[NSView(NSLayerKitGlue) _layoutSublayersOfLayer:] + 1475   com.apple.QuartzCore                0x00007fff882e1e51 -[CALayer layoutSublayers] + 2146   com.apple.AppKit                    0x00007fff8a25a8eb _NSBackingLayerLayoutSublayers + 160
7   com.apple.QuartzCore                0x00007fff882e1a25 CA::Layer::layout_if_needed(CA::Transaction*) + 363
8   com.apple.AppKit                    0x00007fff8a2e0e7e -[NSView _pullInTilesByDrawingAndAddingSubviews] + 839   com.apple.AppKit                    0x00007fff8a2e0e12 -[NSView _pullInExtraTilesForOverdraw] + 87
10  com.apple.AppKit                    0x00007fff8a2e0d7e -[NSView _doIdlePrefetch] + 59
11  com.apple.AppKit                    0x00007fff8a30f6ec -[_NSScrollingConcurrentMainThreadSynchronizer _doIdlePrefetch] + 88
12  com.apple.AppKit                    0x00007fff8a30e287 -[_NSScrollingConcurrentMainThreadSynchronizer _synchronize:completionHandler:] + 48
13  com.apple.AppKit                    0x00007fff8a30e20f __80-[_NSScrollingCon
currentMainThreadSynchronizer initWithSharedData:constantData:]_block_invoke + 1
40
14  libdispatch.dylib                   0x00007fff8dbbd28d _dispatch_client_callout + 8

The first crash log is what I would typically get from them although I don't recall the backend selector being a consistent cause of the crash. It typically crashes in -[SCIContentView viewWillDraw].The second one is the first one I've ever gotten that shows more of the call stack past -[SCIContentView viewWillDraw]. According to this user, the editor has crashed when working in a different window in my application, switching back to the editor, then clicking in the editor to move the cursor but typically only after using the editor for a few hours. It has crashed after opening an existing document too but they didn't say if that had happened early or after hours of use. I personally have had Scintilla crash on me twice. Both times I was in the debugger (with no breakpoints) and closing a document. Both crashes were in -[SCIContentView viewWillDraw]. But I've only had those two crashes out of the thousands of times I've run it under similar circumstances.

I can try to dig up more crash logs from my users but I'm fairly certain it's more of them same.

Neil Hodgson

unread,
Aug 26, 2015, 5:57:18 PM8/26/15
to scintilla...@googlegroups.com
Chinh Nguyen:

I'm currently using version 3.5.7 but this problem has existed since I first started using Scintilla a few years ago.

    viewWillDraw was only implemented 17 months ago and both the traces show it so there is a good chance this is specific to viewWillDraw.

 Here are a couple of partial crash logs:
Application Specific Information:
objc_msgSend() selector name: backend

   The mBackend field that backs the backend property is allocated in the initialiser (initWithFrame:) and deleted in dealloc.
There’s not scope for it going bad except for wild-write scenarios.

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

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000000

VM Regions Near 0:
-->
    __TEXT                 0000000100000000-0000000100da1000 [ 13.6M] r-x/rwx SM=COW  /Applications/Stata/Stata.app/Contents/MacOS/Stata

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   com.sun.Scintilla                   0x000000010180d1e9 Scintilla::Editor::PositionAfterArea(Scintilla::PRectangle) const + 141
1   com.sun.Scintilla                   0x00000001017e8de2

   This could be a NULL or bad pdoc. This could be caused if the application is setting the document (SCI_SETDOCPOINTER), possibly multiplexing a Scintilla instance over multiple documents.

   Both of these are occurring in viewWillDraw in response to adding drawn tiles to the cache during idle time in response to the system’s responsive scrolling thread. One explanation could be that the ScintillaView has been deleted but the background task hasn’t been cancelled quite yet.
 
8   com.apple.AppKit                    0x00007fff8a2e0e7e -[NSView _pullInTilesByDrawingAndAddingSubviews] + 839   com.apple.AppKit                    0x00007fff8a2e0e12 -[NSView _pullInExtraTilesForOverdraw] + 87
10  com.apple.AppKit                    0x00007fff8a2e0d7e -[NSView _doIdlePrefetch] + 59
11  com.apple.AppKit                    0x00007fff8a30f6ec -[_NSScrollingConcurrentMainThreadSynchronizer _doIdlePrefetch] + 88
12  com.apple.AppKit                    0x00007fff8a30e287 -[_NSScrollingConcurrentMainThreadSynchronizer _synchronize:completionHandler:] + 48
13  com.apple.AppKit                    0x00007fff8a30e20f __80-[_NSScrollingCon
currentMainThreadSynchronizer initWithSharedData:constantData:]_block_invoke + 1
40
14  libdispatch.dylib                   0x00007fff8dbbd28d _dispatch_client_callout + 8

I personally have had Scintilla crash on me twice. Both times I was in the debugger (with no breakpoints) and closing a document.

   Check the sequence of your document calls: are you releasing the current document or setting a deallocated document before deleting the ScintillaView? There should always be a valid document so there is little checking that pdoc is set. Perhaps add an assert(pdoc) in ScintillaCocoa::WillDraw for a more explicit failure.  

   Neil

Chinh Nguyen

unread,
Aug 28, 2015, 5:52:58 PM8/28/15
to scintilla-interest, nyama...@me.com

   The mBackend field that backs the backend property is allocated in the initialiser (initWithFrame:) and deleted in dealloc.
There’s not scope for it going bad except for wild-write scenarios.


I noticed that and that's troublesome for me. The user reported they clicked in a different window then clicked back and got the crash so I'm not sure where the wild write would come from.

I can't say that I've noticed the backend selector issue before but I might've glossed over it in the past.
 
   This could be a NULL or bad pdoc. This could be caused if the application is setting the document (SCI_SETDOCPOINTER), possibly multiplexing a Scintilla instance over multiple documents.


I've looked over my code and I use SCI_SETDOCPOINTER in 2 places. A split view and printing. In both cases, I create a new ScintillaView and reference the original document with SCI_GETDOCPOINTER, SCI_ADDREFDOCUMENT, then SCI_SETDOCPOINTER. When the print view or split view are dealloced, I SCI_GETDOCPOINTER then SCI_RELEASEDOCUMENT.

But the user hasn't indicated to me that they had any issues after printing or using a split view or if they've ever used either feature.

   Both of these are occurring in viewWillDraw in response to adding drawn tiles to the cache during idle time in response to the system’s responsive scrolling thread. One explanation could be that the ScintillaView has
been deleted but the background task hasn’t been cancelled quite yet.

That was my first guess as to the cause of the problem. I asked the user if the crashes normally occur immediately after closing a document and he said he didn't think so. He thought that it might be possible that after a document had been closed, he switched to another window, then switched back to a different open document, clicked inside the ScintillaView and then it crashed. Also, the user has had it crash when trying to open a document on disk while a different document is already open.
 
   Check the sequence of your document calls: are you releasing the current document or setting a deallocated document before deleting the ScintillaView? There should always be a valid document so there is little checking that pdoc is set. Perhaps add an assert(pdoc) in ScintillaCocoa::WillDraw for a more explicit failure.  


No, I don't release the current document, only the ScintillaView except for a split view or print view but the original ScintillaView and document are not destroyed in those cases.
  
I'm waiting on some more crash logs to see if I can find any more clues.

I should point out that I am using a tabbed interface so you can have multiple documents open at the same time in the same window. I have verified that my ScintillaViews are being released properly when a tab or window is closed and that there are no leaks. Also, the text editor is just a small part of my application and is primarily used for writing scripts.

Neil Hodgson

unread,
Sep 1, 2015, 9:26:33 AM9/1/15
to scintilla-interest
Chinh Nguyen:

I noticed that and that's troublesome for me. The user reported they clicked in a different window then clicked back and got the crash so I'm not sure where the wild write would come from.

   There’s the recent dragging graphics context bug.

I've looked over my code and I use SCI_SETDOCPOINTER in 2 places. A split view and printing. In both cases, I create a new ScintillaView and reference the original document with SCI_GETDOCPOINTER, SCI_ADDREFDOCUMENT, then SCI_SETDOCPOINTER. When the print view or split view are dealloced, I SCI_GETDOCPOINTER then SCI_RELEASEDOCUMENT.

   One area that is dangerous is performing document manipulation or or deleting ScintillaView objects from within a notification from Scintilla.

That was my first guess as to the cause of the problem. I asked the user if the crashes normally occur immediately after closing a document and he said he didn't think so. He thought that it might be possible that after a document had been closed, he switched to another window, then switched back to a different open document, clicked inside the ScintillaView and then it crashed. Also, the user has had it crash when trying to open a document on disk while a different document is already open.

   In drawRect, there is a dispatch_async. I wonder if it is possible for the view to be deallocated before the block is executed so there should be an retain on self before the dispatch_async? I remember something about variables referenced in a block being retained but that may have been from ARC and Scintilla has ARC turned off.

   Neil

Chinh Nguyen

unread,
Sep 4, 2015, 12:00:24 PM9/4/15
to scintilla-interest, nyama...@me.com


On Tuesday, September 1, 2015 at 8:26:33 AM UTC-5, Neil Hodgson wrote:
Chinh Nguyen:

I noticed that and that's troublesome for me. The user reported they clicked in a different window then clicked back and got the crash so I'm not sure where the wild write would come from.

   There’s the recent dragging graphics context bug.


Interesting. I applied the fix and will send it to the user. I asked if he had used drag and drop at any point but I'm waiting to hear back. I know other users have had crashes with drag and drop within Scintilla but I believe that was a different problem that was fixed when I upgraded to 3.5.7.

The person who submitted the graphics context bug to you was able to deduce the source of the problem. I don't think you can look at the crash logs I submitted and trace it back to an unrestored graphics context so I'm not sure they're the same problem but I'm hopeful. I'd be interested to see what their crash logs looked like.
  
That was my first guess as to the cause of the problem. I asked the user if the crashes normally occur immediately after closing a document and he said he didn't think so. He thought that it might be possible that after a document had been closed, he switched to another window, then switched back to a different open document, clicked inside the ScintillaView and then it crashed. Also, the user has had it crash when trying to open a document on disk while a different document is already open.

   In drawRect, there is a dispatch_async. I wonder if it is possible for the view to be deallocated before the block is executed so there should be an retain on self before the dispatch_async? I remember something about variables referenced in a block being retained but that may have been from ARC and Scintilla has ARC turned off.


From my (limited) understanding of blocks, blocks that are copied (such as from a dispatch) automatically retain object variables within the block whether it's from ARC or manual reference counting so I believe it's fine.

PS, I was wrong about this being a long standing but infrequent problem. I checked and it seems to only be a recent problem.

Neil Hodgson

unread,
Sep 4, 2015, 8:15:30 PM9/4/15
to scintilla...@googlegroups.com
Chinh Nguyen:

> PS, I was wrong about this being a long standing but infrequent problem. I checked and it seems to only be a recent problem.

Depending on what the cut-off is for the recent reports, one potential culprit is the more complex timer code introduced with 3.5.0 in August 2014 since this could (if there are bugs in the implementation) potentially produce a call into Scintilla after the view has been freed or otherwise changed. Tracing document creation/deletion/switching and timer/idler start/stops may be worthwhile.

Neil

Message has been deleted

Chinh Nguyen

unread,
Sep 9, 2015, 9:50:12 AM9/9/15
to scintilla-interest, nyama...@me.com
The previous version of my product where the user first reported the problem is still using version 3.4.1 of Scintilla. 

Message has been deleted

Chinh Nguyen

unread,
Oct 2, 2015, 10:52:44 AM10/2/15
to scintilla-interest
Just got a crash. I actually did very little after launching the app so it was easy to reproduce what I had done to lead up to the crash but I just can't reproduce the crash. All I did when it crashed was to quit the app while the editor was open.

2015-10-02 09:38:05.757 StataSE Debug[62789:50125789] *** Terminating app due to uncaught exception 'CALayerInvalidGeometry', reason: 'CALayer bounds contains NaN: [nan nan; 1141 775]'

*** First throw call stack:

(

0   CoreFoundation                      0x00007fff8cc9203c __exceptionPreprocess + 172

1   libobjc.A.dylib                     0x00007fff8e33076e objc_exception_throw + 43

2   CoreFoundation                      0x00007fff8cc91eed +[NSException raise:format:] + 205

3   QuartzCore                          0x00007fff8a3a8f78 _ZN2CA5Layer10set_boundsERKNS_4RectEb + 226

4   QuartzCore                          0x00007fff8a3a8e29 -[CALayer setBounds:] + 154

5   AppKit                              0x00007fff90bf42f0 -[_NSClipViewBackingLayer setBounds:] + 112

6   AppKit                              0x00007fff90b1ad8e -[NSView(NSInternal) _updateLayerGeometryFromView] + 1159

7   AppKit                              0x00007fff90c08726 -[NSView translateOriginToPoint:] + 187

8   AppKit                              0x00007fff90c06951 -[NSClipView _immediateScrollToPoint:] + 1292

9   AppKit                              0x00007fff90c0639e -[NSClipView scrollToPoint:] + 241

10  AppKit                              0x00007fff90ce5f0e -[NSScrollView scrollClipView:toPoint:] + 75

11  AppKit                              0x00007fff90c0612d -[NSClipView _scrollTo:animateScroll:flashScrollerKnobs:] + 1682

12  AppKit                              0x00007fff90df8c3c -[NSScrollView removeFromSuperview] + 143

13  AppKit                              0x00007fff90c2dd99 -[NSView removeFromSuperviewWithoutNeedingDisplay] + 38

14  AppKit                              0x00007fff90b66698 -[NSView _finalizeWithReferenceCounting] + 1000

15  AppKit                              0x00007fff90b6627e -[NSView dealloc] + 151

16  Scintilla                           0x0000000102d56af9 -[ScintillaView dealloc] + 201


Neil Hodgson

unread,
Oct 2, 2015, 7:16:00 PM10/2/15
to scintilla...@googlegroups.com
China Nguyen:

> Just got a crash. I actually did very little after launching the app so it was easy to reproduce what I had done to lead up to the crash but I just can't reproduce the crash. All I did when it crashed was to quit the app while the editor was open.

This doesn’t involve viewWillDraw so may or may not be the same issue.

Its occurring in finalisation with the backing layer having a bad origin. One area to explore is the shutdown sequence: possibly Scintilla should be explicitly finalising and removing sub-views. Another CALayer that could be involved is the animated find indicator although it should only be created if a search was ever performed.

Scrolling does go through adjustScroll so its possible it is damaging the scroll position but it only sets the y value so shouldn’t be setting a (NaN, NaN) origin. Set a breakpoint/trace on adjustScroll and see if it is called during shutdown. It could detect that it is in finalisation and not change the scroll position.

Neil

Chinh Nguyen

unread,
Oct 14, 2015, 5:08:50 PM10/14/15
to scintilla-interest, nyama...@me.com
Neil Hodgson wrote:
 

   Scrolling does go through adjustScroll so its possible it is damaging the scroll position but it only sets the y value so shouldn’t be setting a (NaN, NaN) origin. Set a breakpoint/trace on adjustScroll and see if it is called during shutdown. It could detect that it is in finalisation and not change the scroll position.


I verified that adjustScroll is not called during shutdown nor when the view or its parents are destroyed.

I got another crash report from the same user who upgraded to El Capitan and this time, they were actually working in another application when my application crashed. I'm inferring that my application was just idle and in the background but I'll verify. 

Date/Time:             2015-10-12 17:44:35.957 -0500
OS Version:            Mac OS X 10.11 (15A284)
Report Version:        11
Anonymous UUID:        F5A824A6-7C82-96A3-C861-7D3B832C628C

Sleep/Wake UUID:       A826E8C2-D767-4D8E-8F78-9FEE5EAD0EED

Time Awake Since Boot: 52000 seconds
Time Since Wake:       1200 seconds

System Integrity Protection: enabled

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

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

VM Regions Near 0x7fc0a94e060:
    MALLOC_LARGE_REUSABLE  00000001467e0000-000000014a16f000 [ 57.6M] rw-/rwx SM=PRV
-->
    __TEXT                 0000123440000000-0000123440860000 [ 8576K] r-x/rwx SM=COW  /System/Library/Extensions/GeForceGLDriver.bundle/Contents/MacOS/GeForceGLDriver

Application Specific Information:
objc_msgSend() selector name: backend


Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libobjc.A.dylib                     0x00007fff98cf8e5d objc_msgSend + 29
1   com.apple.AppKit                    0x00007fff88d0c3d7 -[NSView(NSInternal) _sendViewWillDrawAndRecurse:] + 498
2   com.apple.AppKit                    0x00007fff88d0bf6f -[NSView(NSLayerKitGlue) _layoutSublayersOfLayer:] + 146
3   com.apple.QuartzCore                0x00007fff97b62863 -[CALayer layoutSublayers] + 224
4   com.apple.AppKit                    0x00007fff88d0bed0 _NSBackingLayerLayoutSublayers + 158
5   com.apple.QuartzCore                0x00007fff97b57af0 CA::Layer::layout_if_needed(CA::Transaction*) + 366
6   com.apple.AppKit                    0x00007fff88d3df5e -[NSView _pullInTilesByDrawingAndAddingSubviews] + 83
7   com.apple.AppKit                    0x00007fff88d3df01 -[NSView _pullInExtraTilesForOverdraw] + 87
8   com.apple.AppKit                    0x00007fff88d3de7d -[NSView _doIdlePrefetch] + 37
9   com.apple.AppKit                    0x00007fff88e46f60 -[_NSScrollingConcurrentMainThreadSynchronizer _doIdlePrefetch] + 88
10  com.apple.AppKit                    0x00007fff88e45f7d -[_NSScrollingConcurrentMainThreadSynchronizer _synchronize:completionHandler:] + 48
11  com.apple.AppKit                    0x00007fff88e45f1a __80-[_NSScrollingConcurrentMainThreadSynchronizer initWithSharedData:constantData:]_block_invoke + 144
12  libdispatch.dylib                   0x00007fff8ca18453 _dispatch_client_callout + 8

Neil Hodgson

unread,
Oct 14, 2015, 7:05:18 PM10/14/15
to scintilla...@googlegroups.com
China Nguyen:

> I got another crash report from the same user who upgraded to El Capitan and this time, they were actually working in another application when my application crashed. I'm inferring that my application was just idle and in the background but I'll verify.
> …
> Application Specific Information:
> objc_msgSend() selector name: backend
> …
> 7 com.apple.AppKit 0x00007fff88d3df01 -[NSView _pullInExtraTilesForOverdraw] + 87

When the application is in the background there should be little or no need for drawing. The caret is no longer blinking and any scrolling should have stopped. Drawing could be triggered if your app pushed some data into Scintilla. Or maybe if there had been some memory purging due to strong memory pressure. Is your app memory-intensive or this user memory-constrained?

Is your app eligible for automatic or sudden termination?

https://developer.apple.com/library/mac/documentation/General/Conceptual/MOSXAppProgrammingGuide/CoreAppDesign/CoreAppDesign.html#//apple_ref/doc/uid/TP40010543-CH3-SW27

Neil

Neil Hodgson

unread,
Oct 16, 2015, 1:40:10 AM10/16/15
to scintilla...@googlegroups.com
While I haven’t been able to reproduce the problems in viewWillDraw, I have found a way to produce a similar crash with ‘backend’. This occurs when removing the ScintillaView from a form in response to typing. A call is made to becomeFirstResponder on SCIContentView after the ScintillaView has been deallocated. The implementation of becomeFirstResponder uses mOwner.backend which is no longer valid. To fix this, the NSScrollView which contains the SCIContentView can be removed from the ScintillaView in its dealloc like so:

diff -r b5b60d746cda cocoa/ScintillaView.mm
--- a/cocoa/ScintillaView.mm Wed Oct 14 14:55:30 2015 +1100
+++ b/cocoa/ScintillaView.mm Fri Oct 16 16:17:20 2015 +1100
@@ -1216,6 +1216,9 @@
{
[[NSNotificationCenter defaultCenter] removeObserver:self];
delete mBackend;
+ mBackend = NULL;
+ mContent.owner = nil;
+ [scrollView removeFromSuperview];
[marginView release];
[super dealloc];
}

The NULL setting marks the pointers as dead to ensure they are not used and to make debugging clearer.

Neil

Chinh Nguyen

unread,
Oct 20, 2015, 11:46:03 AM10/20/15
to scintilla-interest, nyama...@me.com
I figured out how I got the editor to crash. You can trigger a crash if the editor is scrolling (from bounce back or momentum scrolling) when the editor is destroyed. I opened a long document, spun the scroll wheel, then used a keyboard shortcut to close the editor as it was scrolling.

This crash still happens with your patch.

I double-checked again and adjustScroll is called in this situation which explains the NaN origin. So I added a check for mOwner.backend and started getting crashes in viewWillDraw and gave up at that point. 

Neil Hodgson

unread,
Oct 22, 2015, 2:38:46 AM10/22/15
to scintilla...@googlegroups.com
Chinh Nguyen

> I double-checked again and adjustScroll is called in this situation which explains the NaN origin. So I added a check for mOwner.backend and started getting crashes in viewWillDraw and gave up at that point.

It appears that responsive scrolling is calling back into the view after the owning ScintillaView has been freed.

Since mOwner should be nulled after the ScintillaView is deallocated, check for that and add similar checks in the calls made for responsive scrolling: viewWillDraw and prepareContentInRect.

Neil

Chinh Nguyen

unread,
Oct 22, 2015, 9:17:27 AM10/22/15
to scintilla-interest, nyama...@me.com


On Thursday, October 22, 2015 at 1:38:46 AM UTC-5, Neil Hodgson wrote:

   Since mOwner should be nulled after the ScintillaView is deallocated, check for that and add similar checks in the calls made for responsive scrolling: viewWillDraw and prepareContentInRect.

Perfect, that's exactly what I did when I took another crack at it. I just wanted to make sure I was taking the right approach. I also applied your timer fix mentioned in another thread so I'm crossing my fingers that they will all take care of the problem.

Neil Hodgson

unread,
Oct 22, 2015, 11:28:50 PM10/22/15
to scintilla-interest
Chinh Nguyen:

> Perfect, that's exactly what I did when I took another crack at it. I just wanted to make sure I was taking the right approach. I also applied your timer fix mentioned in another thread so I'm crossing my fingers that they will all take care of the problem.

The discussed changes appear likely to improve outcomes by avoiding some crashes. However, I’d like to know if there is a better way to disconnect the momentum and bounce back scrolling features when freeing ScintillaView so there is no possibility of receiving calls. Otherwise, every method may have to be protected with "if (mOwner)”.

Neil

Chinh Nguyen

unread,
Oct 23, 2015, 10:30:58 AM10/23/15
to scintilla-interest, nyama...@me.com
On Thursday, October 22, 2015 at 10:28:50 PM UTC-5, Neil Hodgson wrote:

   The discussed changes appear likely to improve outcomes by avoiding some crashes. However, I’d like to know if there is a better way to disconnect the momentum and bounce back scrolling features when freeing ScintillaView so there is no possibility of receiving calls. Otherwise, every method may have to be protected with "if (mOwner)”.

I don't know if you can since the content view is what's receiving the scrolling/draw events and it looks like it's still being referenced even after its owner ScintillaView has released it (and already deleted the backend). One possibility is to wrap up the backend in an NSObject that is to be retained/released by both the ScintillaView and the content view since you can't guarantee the lifecycle of the content view.

Neil Hodgson

unread,
Oct 24, 2015, 4:58:22 AM10/24/15
to scintilla-interest
Chinh Nguyen:

I don't know if you can since the content view is what's receiving the scrolling/draw events and it looks like it's still being referenced even after its owner ScintillaView has released it (and already deleted the backend). One possibility is to wrap up the backend in an NSObject that is to be retained/released by both the ScintillaView and the content view since you can't guarantee the lifecycle of the content view.

   That appears to be a step in fixing this but then the new NSObject will have to either check if the reference to the ScintillaCocoa is NULL because it has been freed or the ScintillaCocoa stays alive but has to be aware of the new state and not try to call back to the ScintillaView. 

   Committed the changes to ScintillaView as

   To try to reproduce the problems, ScintillaTest can now add or remove a second ScintillaView and this is bound to ⌘D. Didn’t produce quite the same failure points as reported by you but there were some failures when removing while scrolling.
Some other changes made to ScintillaTest xib file since Xcode 7 said there was an error.

  Neil
 

Chinh Nguyen

unread,
Oct 26, 2015, 10:50:09 AM10/26/15
to scintilla-interest, nyama...@me.com


On Saturday, October 24, 2015 at 3:58:22 AM UTC-5, Neil Hodgson wrote:
 

Perhaps the change to viewWillDraw should be:

  if (!mOwner) {
    [super viewWillDraw];
    return;
  }

Neil Hodgson

unread,
Oct 27, 2015, 2:58:37 AM10/27/15
to scintilla-interest
Chinh Nguyen:

> Perhaps the change to viewWillDraw should be:
>
> if (!mOwner) {
> [super viewWillDraw];
> return;
> }
>

OK.
http://sourceforge.net/p/scintilla/code/ci/1e061fd729ab1b0db89ebe7532e6f3d7ae569177/

Neil
Reply all
Reply to author
Forward
0 new messages