Date   

find standard about panel

James Walker
 

How can I find the window produced by -[NSApplication
orderFrontStandardAboutPanel:]?  (I’d like to hide the window when my app deactivates.)  I know it’s somewhere in the array -[NSApplication windows], but I don’t know how to identify which one.


Re: Care to opine on a stack trace

Sandor Szatmari
 

Jens,

On Mar 13, 2019, at 14:13, Jens Alfke <jens@...> wrote:



On Mar 13, 2019, at 11:06 AM, Sandor Szatmari <admin.szatmari.net@...> wrote:

I’m not experienced with putting these pieces together… can this be determined from the crash report?  Or, do I need to determine this when a crash actually occurs?

It’s in the crash report near the top, like this:

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

That long hex number is the address.

Thanks here’s what I have,

Exception Type:        EXC_BREAKPOINT (SIGTRAP)
Exception Codes:       0x0000000000000002, 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY

Application Specific Information:
*** CFHash() called with NULL ***


—Jens


Re: Care to opine on a stack trace

 



On Mar 13, 2019, at 11:06 AM, Sandor Szatmari <admin.szatmari.net@...> wrote:

I’m not experienced with putting these pieces together… can this be determined from the crash report?  Or, do I need to determine this when a crash actually occurs?

It’s in the crash report near the top, like this:

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

That long hex number is the address.

—Jens


Re: Care to opine on a stack trace

Sandor Szatmari
 

Jens,

On Mar 13, 2019, at 13:57, Jens Alfke <jens@mooseyard.com> wrote:



On Mar 13, 2019, at 8:16 AM, Sandor Szatmari <admin.szatmari.net@gmail.com> wrote:

I have an app where I see this crash periodically. Does this look to you like the stream is being destroyed before the run loop releases it? Basically an overrelease?
Not exactly. In frame 4 the NSInputStream has been messaged successfully, which almost never happens if it’s already dealloced; you almost always get a crash in objc_msgsend in that case.
Thanks for pointing out this out. That makes sense since presumably in the frames above we are in calls resulting from the stream removing itself which would be hard to explain if it were dealloc’d. Is this the right conclusion?


Instead it looks like something’s wrong with a dictionary managed by the stream. I don’t know exactly what.
Thanks for pointing me in a direction.


What’s the offending memory address in the crash? If it’s zero, that could be a clue.
I’m not experienced with putting these pieces together… can this be determined from the crash report? Or, do I need to determine this when a crash actually occurs?

Can you run the app with NSZombie enabled until the crash reoccurs?
I can and will…

Thanks,
Sandor


—Jens


Re: Care to opine on a stack trace

 

On Mar 13, 2019, at 8:16 AM, Sandor Szatmari <admin.szatmari.net@gmail.com> wrote:

I have an app where I see this crash periodically. Does this look to you like the stream is being destroyed before the run loop releases it? Basically an overrelease?
Not exactly. In frame 4 the NSInputStream has been messaged successfully, which almost never happens if it’s already dealloced; you almost always get a crash in objc_msgsend in that case.

Instead it looks like something’s wrong with a dictionary managed by the stream. I don’t know exactly what.

What’s the offending memory address in the crash? If it’s zero, that could be a clue.
Can you run the app with NSZombie enabled until the crash reoccurs?

—Jens


Care to opine on a stack trace

Sandor Szatmari
 

I have an app where I see this crash periodically. Does this look to you like the stream is being destroyed before the run loop releases it? Basically an overrelease?


Thread 8 Crashed:
0 com.apple.CoreFoundation 0x9a462ce8 CFHash + 200
1 com.apple.CoreFoundation 0x9a465bc2 CFBasicHashFindBucket + 514
2 com.apple.CoreFoundation 0x9a46596b CFDictionaryGetValue + 123
3 com.apple.CoreFoundation 0x9a52fe82 _CFStreamUnscheduleFromRunLoop + 194
4 com.apple.CoreFoundation 0x9a59237d -[__NSCFInputStream removeFromRunLoop:forMode:] + 61
5 net.infoplus.downloader 0x00050544 -[ServerConnectionHandler handleNewServerConnection:] + 1038
6 com.apple.Foundation 0x9b0554d7 -[NSThread main] + 45
7 com.apple.Foundation 0x9b055262 __NSThread__start__ + 1550
8 libsystem_pthread.dylib 0x9bff9780 _pthread_body + 138
9 libsystem_pthread.dylib 0x9bff96f6 _pthread_start + 155
10 libsystem_pthread.dylib 0x9bff6f7a thread_start + 34


Sandor


Re: Continuously update value bug in 10.13

Steve Mills
 

On Mar 2, 2019, at 19:39:00, Alex Zavatone via Groups.Io <zav=mac.com@groups.io> wrote:

IIRC, there is another method that you can check, with something like didEndEditing something like that.

I remember having to go through several on iOS to find what I wanted.
I stopped on that breakpoint as well, and it doesn't help other than point out that it is indeed a bug. Changing the bound value should not cause editing to end. I just want to know if it's been fixed since 10.13.

--
Steve Mills
Drummer, Mac geek


Re: Continuously update value bug in 10.13

Alex Zavatone
 

IIRC, there is another method that you can check, with something like didEndEditing something like that.

I remember having to go through several on iOS to find what I wanted.

On Mar 1, 2019, at 10:23 AM, Steve Mills via Groups.Io <sjmills=mac.com@groups.io> wrote:

Since we finally were able to move up to 10.13 (printing company, historically slow to change), I've noticed that text fields in views and in cell-based table views now exit editing as soon as any character is entered. Setting a symbolic breakpoint on resignFirstResponder I found that the bindings setting "Continuously update value" is causing this. Has this been fixed in 10.14?

Here's the stack down to where it matters.

#0 0x00007fff4de0d6c5 in -[NSTextView(NSSharing) resignFirstResponder] ()
#1 0x00007fff4dd1fc9f in -[NSWindow _realMakeFirstResponder:] ()
#2 0x00007fff4dd08dfb in -[NSControl abortEditing] ()
#3 0x00007fff4e569b87 in _NSDiscardEditingForView ()
#4 0x00007fff4de67a21 in -[NSValueBinder discardEditing] ()
#5 0x00007fff4de269c5 in -[NSController discardEditing] ()
#6 0x00007fff4de73cb4 in -[NSArrayController setContent:] ()
#7 0x00007fff4de7393e in -[NSArrayDetailBinder _refreshDetailContentInBackground:] ()
#8 0x00007fff527ed9c9 in NSKeyValueNotifyObserver ()
#9 0x00007fff52860b9b in -[NSObject(NSKeyValueObservingPrivate) _notifyObserversForKeyPath:change:] ()
#10 0x00007fff4de27064 in -[NSController _notifyObserversForKeyPath:change:] ()
#11 0x00007fff4de2fbf0 in -[NSController observeValueForKeyPath:ofObject:change:context:] ()
#12 0x00007fff527ed9c9 in NSKeyValueNotifyObserver ()
#13 0x00007fff527ed27d in NSKeyValueDidChange ()
#14 0x00007fff5292ac7e in -[NSObject(NSKeyValueObservingPrivate) _changeValueForKeys:count:maybeOldValuesDict:usingBlock:] ()
#15 0x00007fff5292a684 in -[NSObject(NSKeyValueObservingPrivate) _notifyObserversOfChangeFromValuesForKeys:toValuesForKeys:] ()
#16 0x00007fff507cd53b in -[CFPrefsSource forEachObserver:] ()
#17 0x00007fff507cdd60 in -[CFPrefsSource _notifyObserversOfChangeFromValuesForKeys:toValuesForKeys:] ()
#18 0x00007fff508114d2 in __93-[CFPrefsSearchListSource deferredNotifyCausedByLoadingOfChangesFromDictionary:toDictionary:]_block_invoke ()
#19 0x00007fff50835b22 in __44-[_CFXPreferences copyObservationConnection]_block_invoke_3 ()

Steve via iPhone



Continuously update value bug in 10.13

Steve Mills
 

Since we finally were able to move up to 10.13 (printing company, historically slow to change), I've noticed that text fields in views and in cell-based table views now exit editing as soon as any character is entered. Setting a symbolic breakpoint on resignFirstResponder I found that the bindings setting "Continuously update value" is causing this. Has this been fixed in 10.14?

Here's the stack down to where it matters.

#0 0x00007fff4de0d6c5 in -[NSTextView(NSSharing) resignFirstResponder] ()
#1 0x00007fff4dd1fc9f in -[NSWindow _realMakeFirstResponder:] ()
#2 0x00007fff4dd08dfb in -[NSControl abortEditing] ()
#3 0x00007fff4e569b87 in _NSDiscardEditingForView ()
#4 0x00007fff4de67a21 in -[NSValueBinder discardEditing] ()
#5 0x00007fff4de269c5 in -[NSController discardEditing] ()
#6 0x00007fff4de73cb4 in -[NSArrayController setContent:] ()
#7 0x00007fff4de7393e in -[NSArrayDetailBinder _refreshDetailContentInBackground:] ()
#8 0x00007fff527ed9c9 in NSKeyValueNotifyObserver ()
#9 0x00007fff52860b9b in -[NSObject(NSKeyValueObservingPrivate) _notifyObserversForKeyPath:change:] ()
#10 0x00007fff4de27064 in -[NSController _notifyObserversForKeyPath:change:] ()
#11 0x00007fff4de2fbf0 in -[NSController observeValueForKeyPath:ofObject:change:context:] ()
#12 0x00007fff527ed9c9 in NSKeyValueNotifyObserver ()
#13 0x00007fff527ed27d in NSKeyValueDidChange ()
#14 0x00007fff5292ac7e in -[NSObject(NSKeyValueObservingPrivate) _changeValueForKeys:count:maybeOldValuesDict:usingBlock:] ()
#15 0x00007fff5292a684 in -[NSObject(NSKeyValueObservingPrivate) _notifyObserversOfChangeFromValuesForKeys:toValuesForKeys:] ()
#16 0x00007fff507cd53b in -[CFPrefsSource forEachObserver:] ()
#17 0x00007fff507cdd60 in -[CFPrefsSource _notifyObserversOfChangeFromValuesForKeys:toValuesForKeys:] ()
#18 0x00007fff508114d2 in __93-[CFPrefsSearchListSource deferredNotifyCausedByLoadingOfChangesFromDictionary:toDictionary:]_block_invoke ()
#19 0x00007fff50835b22 in __44-[_CFXPreferences copyObservationConnection]_block_invoke_3 ()

Steve via iPhone


Re: unrecognized selector retainedCGImage

Jonathan Taylor
 

Dear all,

Thanks for your replies. It turned out it wasn't due to a zombie pointer, though I did turn on that setting to check (hadn't thought of that as a possibility for this problem).

After quite a lot more poking around (much of it irrelevant in the end!) I realised that it was all down to the fact that under these specific circumstances the offending call to unlockFocus in my code was not preceded by a call to lockFocus. Fixing that bug has solved the problem! I think I was thrown off by the fact that this was only happening on one system and not reproducible on others - which, along with the ultimate crash being in private classes that I was struggling to find information on, primed me to think it was some sort of version-related issue.

Cheers
Jonny.


Re: unrecognized selector retainedCGImage

Jon Gotow
 

On Feb 19, 2019, at 11:04 AM, Jon Gotow <gotow@stclairsoft.com> wrote:

Turn on zombie objects in Xcode. In newer versions of Xcode, it's in the Run > Diagnostics for the project's scheme. I'm trying to remember where this is in Xcode 6 - I _think_ you want to launch the app using Instruments and then use the Zombie module in Instruments.
Oh - here you go. It's in the scheme's Run > Diagnostics tab even back in Xcode 6:

https://code.tutsplus.com/tutorials/what-is-exc_bad_access-and-how-to-debug-it--cms-24544

- Jon


Re: unrecognized selector retainedCGImage

Jon Gotow
 

On Feb 19, 2019, at 3:57 AM, Jonathan Taylor <jonathan.taylor@glasgow.ac.uk> wrote:

The problem is that as far as I can see this is something internal to AppKit, and I’m not sure what is triggering this problem. This is running on OS 10.9.5 (yes, sorry…), built using Xcode 6.2, with both deployment target and SDK set to 10.9. Can anyone suggest what the problem is, or what I might do to diagnose it further?
As Quincey said, it looks like you've got a zombie pointer that's now pointing to an NSWindowGraphicsContext instead of the original, now-deallocated NSSnapshotBitmapGraphicsContext.

Turn on zombie objects in Xcode. In newer versions of Xcode, it's in the Run > Diagnostics for the project's scheme. I'm trying to remember where this is in Xcode 6 - I _think_ you want to launch the app using Instruments and then use the Zombie module in Instruments.

- Jon


Re: unrecognized selector retainedCGImage

Quincey Morris
 

On Feb 19, 2019, at 02:57 , Jonathan Taylor <jonathan.taylor@...> wrote:

The problem is that as far as I can see this is something internal to AppKit

I suggest that you start with most mundane possibility, that this is a zombie object.

My guess is that this is one of those crashes that can happen when breaking down a UI, such as when a window is closing. It’s easy to have a dangling reference to a weakly reference object that no longer exists.

This is based on seeing:

20  Spim GUI                            0x000df4cc __36-[SpimApplication stopVideoSession:]_block_invoke + 460

in the backtrace, trickling down to a KVO observer being notified:

9   Spim GUI                            0x00141977 -[GUIMovieBuilder observeValueForKeyPath:ofObject:change:context:] + 119

which then looks like it’s trying to *create* a NSImage:

8   Spim GUI                            0x001416b3 -[GUIMovieBuilder updateCurrentFrameImage] + 1747

which looks like it’s trying use some current window or view context:

5   AppKit                              0x903d7ed8 +[NSCGImageSnapshotRep _unlockFocusAndPerformBlockUsingCGImageAndCapturingContext:] + 129

If the window has already destroyed its view hierarchy, this might not work so well.

Unfortunately, this isn’t an easy kind of problem to debug. The answer is usually to nil some non-owning “delegate” reference somewhere, but finding where and when can be challenging.


unrecognized selector retainedCGImage

Jonathan Taylor
 

Hi all,

Can anybody advise on the following exception/crash that I am encountering? The issue is:
[NSWindowGraphicsContext retainedCGImage]: unrecognized selector sent to instance
The problem is that as far as I can see this is something internal to AppKit, and I’m not sure what is triggering this problem. This is running on OS 10.9.5 (yes, sorry…), built using Xcode 6.2, with both deployment target and SDK set to 10.9. Can anyone suggest what the problem is, or what I might do to diagnose it further?

Thanks
Jonny



Application Specific Information:
*** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[NSWindowGraphicsContext retainedCGImage]: unrecognized selector sent to instance 0x79828bf0'

Application Specific Backtrace 1:
0 CoreFoundation 0x9984e471 __raiseError + 193
1 libobjc.A.dylib 0x99329091 objc_exception_throw + 162
2 CoreFoundation 0x99852cb3 -[NSObject(NSObject) doesNotRecognizeSelector:] + 275
3 CoreFoundation 0x9979e522 ___forwarding___ + 1010
4 CoreFoundation 0x9979e10e _CF_forwarding_prep_0 + 14
5 AppKit 0x903d7ed8 +[NSCGImageSnapshotRep _unlockFocusAndPerformBlockUsingCGImageAndCapturingContext:] + 129
6 AppKit 0x903d7e2b +[NSCGImageSnapshotRep unlockFocusCreatingCGImageSnapshotRep] + 138
7 AppKit 0x903d7d65 -[NSImage unlockFocus] + 204
8 Spim GUI 0x001416b3 -[GUIMovieBuilder updateCurrentFrameImage] + 1747
9 Spim GUI 0x00141977 -[GUIMovieBuilder observeValueForKeyPath:ofObject:change:context:] + 119
10 Foundation 0x932a39ef NSKeyValueNotifyObserver + 386
11 Foundation 0x932a2e6d NSKeyValueDidChange + 270
12 Foundation 0x933564f6 -[NSObject(NSKeyValueObserverNotification) didChange:valuesAtIndexes:forKey:] + 120
13 Foundation 0x93360934 -[NSKeyValueNotifyingMutableArray insertObject:atIndex:] + 184
14 AppKit 0x906a4572 -[NSArrayDetailBinder _performArrayBinderOperation:singleObject:multipleObjects:singleIndex:multipleIndexes:selectionMode:] + 1553
15 AppKit 0x906a48d0 -[NSArrayDetailBinder insertObjectIntoMasterArrayRelationship:atIndex:selectionMode:] + 78
16 AppKit 0x9069f1ac -[NSArrayController _insertObject:atArrangedObjectIndex:objectHandler:] + 190
17 AppKit 0x9069f562 -[NSArrayController insertObject:atArrangedObjectIndex:] + 441
18 AppKit 0x9069ef51 -[NSArrayController addObject:] + 160
19 Spim GUI 0x0013fbfa -[GUIMovieBuilder addSequenceForURL:] + 186
20 Spim GUI 0x000df4cc __36-[SpimApplication stopVideoSession:]_block_invoke + 460
21 Spim GUI 0x000e1533 __40+[ImageSaver afterAllBacklogCleared:do:]_block_invoke + 259
22 libdispatch.dylib 0x98c49386 _dispatch_client_callout + 50
23 libdispatch.dylib 0x98c50ddf _dispatch_source_latch_and_call + 150
24 libdispatch.dylib 0x98c4bcf8 _dispatch_source_invoke + 422
25 libdispatch.dylib 0x98c51a24 _dispatch_main_queue_callback_4CF + 207
26 CoreFoundation 0x997a7fae __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 14
27 CoreFoundation 0x9975f3c9 __CFRunLoopRun + 1897
28 CoreFoundation 0x9975e9ea CFRunLoopRunSpecific + 394
29 CoreFoundation 0x9975e84b CFRunLoopRunInMode + 123
30 HIToolbox 0x95850b5d RunCurrentEventLoopInMode + 259
31 HIToolbox 0x958508e2 ReceiveNextEventCommon + 526
32 HIToolbox 0x958506bd _BlockUntilNextEventMatchingListInModeWithFilter + 92
33 AppKit 0x902d4349 _DPSNextEvent + 1602
34 AppKit 0x902d3870 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 119
35 AppKit 0x902c615c -[NSApplication run] + 727
36 AppKit 0x902aeff8 NSApplicationMain + 1165
37 libdyld.dylib 0x90ece701 start + 1


Need help with combining generics, protocols and protocol extensions

Rick Aurbach
 

This is a Swift usage question.

I am working on a family of UI objects which share some common behaviors. Having done several, it is time to refactor (for all of the obvious reasons).

I would like to implement these classes using both generic and non-generic objects interconnected via protocols (with protocol extensions). And I'm having a really hard time, which proves that I really don't understand this part of the Swift language. The attached PDF describes some of what I'm trying to do.

Can you help me get my head around this?

Thanks,

Rick Aurbach


Re: Autolayout(?) question

John Brownie
 

I will file a bug. The reason for using Xcode 9 is that there's a library that depends on the GNU stdc++ library, and the effort to bring that into Xcode 10 is too much to bother at this point.

I haven't used the graphics debugging tools much, but they don't seem to help. I can't get at the ones under Rendering, as they are all disabled.

John

Gary L. Wade wrote on 13/12/18 22:32:

It could only be an issue while using the debugger; is there a reason for not using a more modern Xcode?  Regardless, you should definitely file a bug report, including a sysdiagnose, your log from the LLDB console, and possibly a screen recording of it happening. If you’ve got a small enough app that can reproduce it, include that as well. There’s also some graphics debugging tools you could use to dirty views in different colors that might be useful.

On Dec 13, 2018, at 8:00 AM, John Brownie <john_brownie@...> wrote:

I should add that it's a window in my app, not in Xcode. Running outside the debugger, it appears to be fine, but the exception stops me being able to check on some other issues related to the window's functionality.

John

--
John Brownie
Mussau-Emira language, New Ireland Province, Papua New Guinea
Kouvola, Finland


Re: Autolayout(?) question

Gary L. Wade
 

It could only be an issue while using the debugger; is there a reason for not using a more modern Xcode?  Regardless, you should definitely file a bug report, including a sysdiagnose, your log from the LLDB console, and possibly a screen recording of it happening. If you’ve got a small enough app that can reproduce it, include that as well. There’s also some graphics debugging tools you could use to dirty views in different colors that might be useful.

On Dec 13, 2018, at 8:00 AM, John Brownie <john_brownie@...> wrote:

I should add that it's a window in my app, not in Xcode. Running outside the debugger, it appears to be fine, but the exception stops me being able to check on some other issues related to the window's functionality.

John


Re: Autolayout(?) question

John Brownie
 

I should add that it's a window in my app, not in Xcode. Running outside the debugger, it appears to be fine, but the exception stops me being able to check on some other issues related to the window's functionality.

John


Re: Autolayout(?) question

John Brownie
 

Nobody? Here's the backtrace, if it helps:

    0   AppKit                              0x00007fff29b3657e -[NSWindow(NSDisplayCycle) _postWindowNeedsDisplayUnlessPostingDisabled] + 1964
    1   AppKit                              0x00007fff29bc65b1 -[NSWindow _enablePosting] + 302
    2   AppKit                              0x00007fff29bbf1f1 -[NSView _oldDisplayRectIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:] + 2598
    3   AppKit                              0x00007fff29bbe569 -[NSView _displayRectIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:] + 253
    4   AppKit                              0x00007fff29bbb152 -[NSView displayIfNeeded] + 1300
    5   AppKit                              0x00007fff29bb7ee8 -[NSWindow displayIfNeeded] + 283
    6   AppKit                              0x00007fff29bb7d27 __NSWindowGetDisplayCycleObserverForDisplay_block_invoke + 722
    7   AppKit                              0x00007fff29bb2e2a NSDisplayCycleObserverInvoke + 170
    8   AppKit                              0x00007fff29bb299f NSDisplayCycleFlush + 1073
    9   QuartzCore                          0x00007fff3751153b _ZN2CA11Transaction19run_commit_handlersE18CATransactionPhase + 49
    10  QuartzCore                          0x00007fff37510f02 _ZN2CA11Transaction6commitEv + 186
    11  AppKit                              0x00007fff29bb2305 __65+[CATransaction(NSCATransaction) NS_setFlushesWithDisplayRefresh]_block_invoke + 274
    12  CoreFoundation                      0x00007fff2c5bb9cd __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 23
    13  CoreFoundation                      0x00007fff2c5bb902 __CFRunLoopDoObservers + 452
    14  CoreFoundation                      0x00007fff2c55d429 __CFRunLoopRun + 1166
    15  CoreFoundation                      0x00007fff2c55cd48 CFRunLoopRunSpecific + 463
    16  HIToolbox                           0x00007fff2b7f3ab5 RunCurrentEventLoopInMode + 293
    17  HIToolbox                           0x00007fff2b7f36f4 ReceiveNextEventCommon + 371
    18  HIToolbox                           0x00007fff2b7f3568 _BlockUntilNextEventMatchingListInModeWithFilter + 64
    19  AppKit                              0x00007fff29aae363 _DPSNextEvent + 997
    20  AppKit                              0x00007fff29aad102 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1362
    21  AppKit                              0x00007fff2a043eae -[NSComboBoxCell filterEvents:] + 2747
    22  AppKit                              0x00007fff2a044d48 -[NSComboBoxCell popUp:] + 558
    23  AppKit                              0x00007fff29da760b -[NSApplication(NSResponder) sendAction:to:from:] + 312
    24  AppKit                              0x00007fff29e128b6 -[NSControl sendAction:to:] + 86
    25  AppKit                              0x00007fff29e127e8 __26-[NSCell _sendActionFrom:]_block_invoke + 136
    26  AppKit                              0x00007fff29e126ea -[NSCell _sendActionFrom:] + 178
    27  AppKit                              0x00007fff29e3f755 -[NSButtonCell _sendActionFrom:] + 97
    28  AppKit                              0x00007fff29e91412 __48-[NSCell trackMouse:inRect:ofView:untilMouseUp:]_block_invoke + 82
    29  AppKit                              0x00007fff29e10b7d -[NSCell trackMouse:inRect:ofView:untilMouseUp:] + 1231
    30  AppKit                              0x00007fff29e3f4a9 -[NSButtonCell trackMouse:inRect:ofView:untilMouseUp:] + 698
    31  AppKit                              0x00007fff2a0430bf -[NSComboBoxCell trackMouse:inRect:ofView:untilMouseUp:] + 532
    32  AppKit                              0x00007fff2a04101c -[NSComboBox mouseDown:] + 345
    33  AppKit                              0x00007fff29ce91eb -[NSWindow(NSEventRouting) _handleMouseDownEvent:isDelayedEvent:] + 5668
    34  AppKit                              0x00007fff29c1d223 -[NSWindow(NSEventRouting) _reallySendEvent:isDelayedEvent:] + 2319
    35  AppKit                              0x00007fff29c1c6c9 -[NSWindow(NSEventRouting) sendEvent:] + 481
    36  AppKit                              0x00007fff29ab9954 -[NSApplication(NSEvent) sendEvent:] + 336
    37  AppKit                              0x00007fff29aa719d -[NSApplication run] + 755
    38  AppKit                              0x00007fff29a968a3 NSApplicationMain + 780
    39  Ukelele                             0x00000001001f3310 main + 48
    40  libdyld.dylib                       0x00007fff5979eed9 start + 1
    41  ???                                 0x0000000000000003 0x0 + 3


Re: Need help understanding a threading issue

Rick Aurbach
 

Okay, I've got it.

The problem was that I was calling OperationQueue.main.addOperation(..) from an Operation. And that call was both capturing "self" and was the last piece of work in the Operation's main(). So immediately after queuing the new main-thread operation, the caller was marked finished and was deleted. So by the time the main-thread operation executed, its attempt to capture "self" failed and (like all good closures) exited safely.

SOLUTION: class A is the controller for the process. It holds the operation queue as a property and sends it the addOperations([...]) call that begins the whole background process. One Operation wants to display status (doing UI on the main thread). In the working case, it does so by calling a method in class A which (in turn) issues the appropriate OperationQueue.main.addOperation{...} call. This way, when the main-thread operation actually runs, the "self" it captures is class A (which still exists) rather than the Operation (which no longer does).

541 - 560 of 1422