Receiver type for instance message is a forward declaration

相关文章推荐

玩足球的篮球 · 運用遊戲化機器人英語共讀活動優化國高中生性別 ...· 1 周前 ·

I'm building for iOS 9.3, and am using NSOperationQueue throughout. Once in a while, NSOperationQueue -addOperation: throws an exception. I guess this is a well-known bug going all the way back to 2008. I found Mike Ash's writeup on the issue, and have downloaded his replacement class, RAOperationQueue. However, it was written long ago for GC not ARC. I have one remaining problem in converting the code.

- (BOOL)_runOperationFromList: (RAAtomicListRef *)listPtr sourceList: (RAAtomicListRef *)sourceListPtr
{
RAOperation *op = [self _popOperation: listPtr];
if( !op )
{
*listPtr = RAAtomicListSteal( sourceListPtr );
// source lists are in LIFO order, but we want to execute operations in the order they were enqueued
// so we reverse the list before we do anything with it
RAAtomicListReverse( listPtr );
op = [self _popOperation: listPtr];
}

if( op )
[op run]; <-- ERROR HERE

return op != nil;
}

The error I'm getting is: Receiver type 'RAOperation' for instance message is a forward declaration.

What does this error mean, and how can I fix it?
-Carl

_______________________________________________

Cocoa-dev mailing list (Cocoa-***@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/gegs%40ml-in.na

Post by Carl Hoefs
I'm building for iOS 9.3, and am using NSOperationQueue throughout. Once in a while, NSOperationQueue -addOperation: throws an exception. I guess this is a well-known bug going all the way back to 2008. I found Mike Ash's writeup on the issue, and have downloaded his replacement class, RAOperationQueue. However, it was written long ago for GC not ARC. I have one remaining problem in converting the code.
- (BOOL)_runOperationFromList: (RAAtomicListRef *)listPtr sourceList: (RAAtomicListRef *)sourceListPtr
{
RAOperation *op = [self _popOperation: listPtr];
if( !op )
{
*listPtr = RAAtomicListSteal( sourceListPtr );
// source lists are in LIFO order, but we want to execute operations in the order they were enqueued
// so we reverse the list before we do anything with it
RAAtomicListReverse( listPtr );
op = [self _popOperation: listPtr];
}
if( op )
[op run]; <-- ERROR HERE
return op != nil;
}
The error I'm getting is: Receiver type 'RAOperation' for instance message is a forward declaration.
What does this error mean, and how can I fix it?

It means you haven't #included the header with the @interface declaration for RAOperation.

John.
_______________________________________________

Cocoa-dev mailing list (Cocoa-***@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/gegs%40ml-in.narkive.net

Indeed, that silenced the error, thanks!
I would have thought that this earlier line would have been flagged if RAOperation.h hadn't been included:

RAOperation *op = [self _popOperation: listPtr];

-Carl

_______________________________________________

Cocoa-dev mailing list (Cocoa-***@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/gegs%40ml-in.narkive.net

This email sent to ***@ml-in.nar

Post by Carl Hoefs
RAOperation *op = [self _popOperation: listPtr];

There must be a forward declaration (“@class RAOperation”) somewhere above, possibly in your class’s header. After a forward declaration, you can refer to the class and declare references to instances. But since the compiler has no idea what the class’s interface is, or even what it’s superclass is, it will complain if you try to message a reference.

—Jens
_______________________________________________

Cocoa-dev mailing list (Cocoa-***@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/gegs%40ml-in.narkive.

Post by Carl Hoefs
Once in a while, NSOperationQueue -addOperation: throws an exception. I guess this is a well-known bug going all the way back to 2008. I found Mike Ash's writeup on the issue, and have downloaded his replacement class, RAOperationQueue. However, it was written long ago for GC not ARC.
"Mac OS X 10.5.7 has shipped and includes a fix for the NSOperationQueue bug that I discovered late last year. I have run all of my old test cases against 10.5.7 and it appears to perform as advertised. As far as I can see, NSOperationQueue is now safe to use.”

These days, if I had any doubts about NSOperationQueue, I’d switch to using GCD directly. There’s very little that NSOperationQueue does that GCD doesn’t, and I must admit I’ve never regarded NSOperationQueue as superior**, apart from the fact that it got here first. (IIRC) NSOperationQueue started to displace raw threading only just before GCD arrived on the scene.

** There is, however, a small cloud hovering over GCD. This has been reported in the developer forums independently by different developers. Apparently, a GCD queue (under what circumstances isn’t clear) can use additional memory for each block that’s ever queued. That is, if a queue has historically run and disposed of N blocks, it will keep N * X bytes of memory around, even though its queue might currently be empty. The value of X is very small, so you have to go through tens of thousands of blocks before you’d even notice. It’s not clear if this is a memory leak, or a cache that would eventually stop increasing in size and/or be reclaimed.

_______________________________________________

Cocoa-dev mailing list (Cocoa-***@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/gegs%40ml-in.narkive.net

This email sent t
Can we come up with a suitable set of tests to replicate and verify this, like a bunch of dispatch_async calls to increment an NSInteger and then to decrement the NSInteger that repeats while true?

Sent from my iPhone

Post by Quincey Morris
** There is, however, a small cloud hovering over GCD. This has been reported in the developer forums independently by different developers. Apparently, a GCD queue (under what circumstances isn’t clear) can use additional memory for each block that’s ever queued. That is, if a queue has historically run and disposed of N blocks, it will keep N * X bytes of memory around, even though its queue might currently be empty. The value of X is very small, so you have to go through tens of thousands of blocks before you’d even notice. It’s not clear if this is a memory leak, or a cache that would eventually stop increasing in size and/or be reclaimed.

_______________________________________________

Cocoa-dev mailing list (Cocoa-***@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/gegs%40ml-in.narkive.net

This email sent to ***@ml-in.narkive.ne

Post by Alex Zavatone
Can we come up with a suitable set of tests to replicate and verify this
class ViewController: UIViewController {
let backgroundQueue = dispatch_queue_create("backgroundQueue", DISPATCH_QUEUE_SERIAL);
var tickTimer: NSTimer?
var cancelTimer: NSTimer?
override func viewDidLoad() {
super.viewDidLoad()
tickTimer = NSTimer.scheduledTimerWithTimeInterval(0.1, target: self, selector: "timerFired:", userInfo: nil, repeats: true)
cancelTimer = NSTimer.scheduledTimerWithTimeInterval(30, target: self, selector: "cancelTimerFired:", userInfo: nil, repeats: false)
}
func timerFired(timer: NSTimer) {
for _ in 0..<100 {
dispatch_async(backgroundQueue, { () -> Void in
// TODO: some calculation. However, it does not matter
})
}
}
func cancelTimerFired(timer: NSTimer) {
tickTimer?.invalidate()
}
}

But it only be a problem with specific OS X or iOS versions. I haven’t checked lately.

_______________________________________________

Cocoa-dev mailing list (Cocoa-***@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/gegs%40ml-in.narkive.net

This em

Post by Quincey Morris

I've noticed infrequent objcExceptionThrow()s using NSOperationQueue for quite a while now, always thinking it must be something I'm doing. Unfortunately, the exception appears so seldom that I've never had the time to look into the issue at the time it happens. All I'm doing is -addOperation: when it blows. I can't reproduce it at will. I should have taken a stack trace when it occurred today.

Sadly, RAOperationQueue et al is suffering from code rot. I couldn't get it to work at all. Thanks for the GCD suggestion as an alternative, I'll go with it. (It isn't that NSOperationQueue is superior to GCD or not, it was just a very conveniently-oriented object to use.)
-Carl

_______________________________________________

Cocoa-dev mailing list (Cocoa-***@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/gegs%40ml-in.narkive.net

This email sent to geg

Post by Quincey Morris
These days, if I had any doubts about NSOperationQueue, I’d switch to using GCD directly. There’s very little that NSOperationQueue does that GCD doesn’t

Alas, there appear to be no GCD dispatch queue introspection functions, specifically to find out what is executing (if anything) and what's waiting in the queue. Or did I overlook something?
-Carl

_______________________________________________

Cocoa-dev mailing list (Cocoa-***@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/gegs%40ml-in.narkive.net

Post by Carl Hoefs
Alas, there appear to be no GCD dispatch queue introspection functions, specifically to find out what is executing (if anything) and what's waiting in the queue. Or did I overlook something?

Also, no, I don’t think so. There is dispatch_get/set_context, but the documentation is unclear as to whether these work on queued blocks. Cancelling GCD operations is also a bit more primitive than you would like. The other thing that NSOperationQueue can do that I don’t think GCD can do is limit the “width” of a concurrent queue (AFAIK).

If you need to manipulate the queue operations themselves, this does seem like something of a code smell in regard to GCD. In that case, NSOperationQueue is probably a better choice. Perhaps it’s worth going back to that, in the hope that your crashes get more frequent, and you can investigate what really causes them.
_______________________________________________

Cocoa-dev mailing list (Cocoa-***@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/gegs%40ml-in.narkive.net

This email

Post by Quincey Morris
Perhaps it’s worth going back to that, in the hope that your crashes get more frequent, and you can investigate what really causes them.

At last, it blew again! Can someone interpret this? The context is that I touched a button in my iOS 9.3 app which invokes a method that creates an NSOperation and enqueues it to an established NSOperationQueue "upload queue".
-Carl

2016-05-10 13:29:16.980 iApp[2465:2101493] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: '<CFArray 0x14e5e450 [0x378fd840]>{type = mutable-small, count = 1, values = (
0 : +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Timestamp: 27419184482629
Total Latency: 33461 us
SenderID: 0x000000010000023E
BuiltIn: 0
ValueType: Absolute
EventType: Digitizer
DisplayIntegrated: 0
TransducerType: Finger
TransducerIndex: 3
Identity: 2
EventMask: 2051
Events: Range Touch FromEdgeTip
ButtonMask: 0
Range: 0
Touch: 0
Pressure: 0.000000
AuxiliaryPressure: 0.000000
Twist: 90.000000
GenerationCount: 0
WillUpdateMask: 00000000
DidUpdateMask: 00000000
X: 467.500000
Y: 294.500000
Z: 0.000000
Quality: 0.000000
Density: 0.000000
Irregularity: 0.000000
MajorRadius: 0.000000
MinorRadius: 0.000000
Accuracy: 0.011230
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

)}: An -observeValueForKeyPath:ofObject:change:context: message was received but not handled.
Key path: operations
Observed object: <NSOperationQueue: 0x14eae190>{name = 'Upload Queue'}
Change: {
kind = 1;
}
Context: 0x0'
*** First throw call stack:
(0x20d19b8b 0x204d6dff 0x20d19ad1 0x2151cd7d 0x214a3d81 0x21482fe3 0x21482c3b 0x2151e311 0x214822d1 0x2152f761 0x12d06d 0x25322521 0x253224b1 0x2530a3eb 0x25321dd1 0x25321a3f 0x2531a3c7 0x252eac85 0x252e9229 0x20cdba67 0x20cdb657 0x20cd99bf 0x20c28289 0x20c2807d 0x22244af9 0x253532c5 0x148dd7 0x208d4873)
libc++abi.dylib: terminating with uncaught exception of type NSException
(lldb) bt
* thread #1: tid = 0x2010f5, 0x209a7c5c libsystem_kernel.dylib`__pthread_kill + 8, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
frame #0: 0x209a7c5c libsystem_kernel.dylib`__pthread_kill + 8
frame #1: 0x20a4db46 libsystem_pthread.dylib`pthread_kill + 62
frame #2: 0x2093c0c4 libsystem_c.dylib`abort + 108
frame #3: 0x204b27dc libc++abi.dylib`abort_message + 108
frame #4: 0x204cb6a0 libc++abi.dylib`default_terminate_handler() + 268
frame #5: 0x204d7098 libobjc.A.dylib`_objc_terminate() + 192
frame #6: 0x204c8e16 libc++abi.dylib`std::__terminate(void (*)()) + 78
frame #7: 0x204c88f6 libc++abi.dylib`__cxa_rethrow + 102
frame #8: 0x204d6f46 libobjc.A.dylib`objc_exception_rethrow + 42
frame #9: 0x20c2830e CoreFoundation`CFRunLoopRunSpecific + 650
frame #10: 0x20c2807c CoreFoundation`CFRunLoopRunInMode + 108
frame #11: 0x22244af8 GraphicsServices`GSEventRunModal + 160
frame #12: 0x253532c4 UIKit`UIApplicationMain + 144
* frame #13: 0x00148dd6 iApp`main(argc=1, argv=0x003a7bd4) + 122 at main.m:14
(lldb)

_______________________________________________

Cocoa-dev mailing list (Cocoa-***@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/gegs%40ml-in.narkive.net

This email sent to ***@ml-in.n

Post by Carl Hoefs
)}: An -observeValueForKeyPath:ofObject:change:context: message was received but not handled.
Key path: operations
Observed object: <NSOperationQueue: 0x14eae190>{name = 'Upload Queue'}

An object got a KVO notification but doesn’t have a observer method to handle it. Looks like the object is an NSArray, which is strange — the most likely thing is that it’s the wrong object, and the real observer got dealloced. Try enabling zombies.

—Jens
_______________________________________________

Cocoa-dev mailing list (Cocoa-***@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/gegs%40ml-in.narkive.net

This email sent

Post by Carl Hoefs
At last, it blew again!
An -observeValueForKeyPath:ofObject:change:context: message was received but not handled.
Key path: operations
Observed object: <NSOperationQueue: 0x14eae190>{name = 'Upload Queue'}
Change: {
kind = 1;
}
Context: 0x0

So, some object has established itself as an observer of changes to the “operations” property of the NSOperationQueue named “Upload Queue”, but has failed to act on the observed change. Since the message says “received but not handled”, the likelihood is that the observer object *has* a method named 'observeValueForKeyPath:ofObject:change:context:’ (or one of its superclasses does), and is invoking the ‘super’ method to pass the change upwards to an ancestor class, but nothing actually handles it.

The most likely cause is that the observer registered itself using ‘addObserver:forKeyPath:options:context:’ specifying a nil context, but is checking for a different context in 'observeValueForKeyPath:ofObject:change:context:’.

It’s also possible that the exception message means something more obscure, in which case the cause may be more complicated, but you should search your code for ‘addObserver’ and ‘observeValueForKeyPath’, and make sure that the context is set and checked consistently. (Your code should *never* use a nil context explicitly.)

_______________________________________________

Cocoa-dev mailing list (Cocoa-***@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/gegs%40ml-in.narkiv

Post by Quincey Morris

So, some object has established itself as an observer of changes to the “operations” property of the NSOperationQueue named “Upload Queue”, but has failed to act on the observed change. Since the message says “received but not handled”, the likelihood is that the observer object *has* a method named 'observeValueForKeyPath:ofObject:change:context:’ (or one of its superclasses does), and is invoking the ‘super’ method to pass the change upwards to an ancestor class, but nothing actually handles it.
The most likely cause is that the observer registered itself using ‘addObserver:forKeyPath:options:context:’ specifying a nil context, but is checking for a different context in 'observeValueForKeyPath:ofObject:change:context:’.
It’s also possible that the exception message means something more obscure, in which case the cause may be more complicated, but you should search your code for ‘addObserver’ and ‘observeValueForKeyPath’, and make sure that the context is set and checked consistently. (Your code should *never* use a nil context explicitly.)

Yes, yes, and yes! I'm using a nil context. I'm not sure how context is to be used here... Is this an arbitrary value that I check in -observeValueForKeyPath?
-Carl

_______________________________________________

Cocoa-dev mailing list (Cocoa-***@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/gegs%40ml-in.narkive.net

T

Post by Carl Hoefs
Yes, yes, and yes! I'm using a nil context. I'm not sure how context is to be used here... Is this an arbitrary value that I check in -observeValueForKeyPath?

Yes, but I’m not aware of it being required … what goes wrong if it’s NULL, Quincey?

—Jens
_______________________________________________

Cocoa-dev mailing list (Cocoa-***@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/gegs%40ml-

Post by Jens Alfke

Post by Carl Hoefs
Yes, yes, and yes! I'm using a nil context. I'm not sure how context is to be used here... Is this an arbitrary value that I check in -observeValueForKeyPath?

Yes, but I’m not aware of it being required … what goes wrong if it’s NULL, Quincey?
—Jens

nothing goes wrong if it’s null, however you can’t tell which observations are yours and which belong to one of the other classes in the inheritance chain who are also potentially using KVO.

However lots of people use nil for it and get away with it, but don’t. You will one-day handle the KVO notifications for something which isn’t you and starve it of doing so.

Either way - this KVO notification has been passed to the superclass hence the exception. I’d doubt it’s because of the context, more likely that he’s comparing the notification name string incorrectly and not handling it, or handing the KVO and then *still* calling the superclass method.

_______________________________________________

Cocoa-dev mailing list (Cocoa-***@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/gegs%40ml-in.narkive.net

This email sent to g

Post by Jens Alfke
what goes wrong if it’s NULL

If anything else uses NULL, then your observation is not uniquely identified, which means that:

— you might respond to a notification registered by an ancestor class of your observer instance, breaking some of its functionality;

— *removing* the observer can remove the wrong observation.

Since there are believed to be a few cases where Cocoa registers its own observations in classes that apps will actually subclass, and Cocoa uses NULL for such contexts, apps should avoid NULL. In addition, for uniqueness within the app’s code, it’s easiest to use something other than NULL that’s known to be unique to the current compilation unit (usually).

This is also why a version of ‘removeObserver’ that takes a ‘context’ parameter was retrofitted, several OS X versions ago.

_______________________________________________

Cocoa-dev mailing list (Cocoa-***@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/gegs%40ml-in.narkive.net

T

Post by Carl Hoefs
I'm not sure how context is to be used here
static void* kvoContext = &kvoContext;

This exploits a quirk of C to initialize the static variable as containing its own address. That means you can specify the ‘context:’ parameter as EITHER ‘kvoContext’ OR ‘&kvoContext’, so that forgetting the & is harmless.

_______________________________________________

Cocoa-dev mailing list (Cocoa-***@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/gegs%40ml-in.narkive.net

This email

Post by Quincey Morris

Post by Carl Hoefs
I'm not sure how context is to be used here
static void* kvoContext = &kvoContext;

Okay... It appears that for some odd reason, once in a blue moon, 'object' and 'keyPath' aren't what they're supposed to be, so I super it, and it blows.

- (void) observeValueForKeyPath:(NSString *)keyPath
ofObject:(id)object
change:(NSDictionary *)change
context:(void *)context
{
if ((object == uploadQueue) && [keyPath isEqualToString:@"operations"]) {
[self performSelectorOnMainThread:@selector(displayQueueInfo)
withObject:nil
waitUntilDone:NO];
} else {
[super observeValueForKeyPath:keyPath
ofObject:object
change:change
context:context];
}
}

I will set 'context' and use it in my check instead.
-Carl

_______________________________________________

Cocoa-dev mailing list (Cocoa-***@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/gegs%40ml-in.narkive.net

This ema

Post by Carl Hoefs
Okay... It appears that for some odd reason, once in a blue moon, 'object' and 'keyPath' aren't what they're supposed to be, so I super it, and it blows.
….
I will set 'context' and use it in my check instead.
-Carl

Well you should also figure out why object and keyPath aren’t what they are supposed to be, because that’s the actual problem here, just checking the context isn’t really going to help you if you are getting notifications for keyPath ‘foo’ when you were expecting them for keyPath ‘bar’. You’ll just hide the issue until it comes back to bite you another way. If it was a case of another KVO up the inheritance chain then it wouldn’t fail if you passed the message to super. Cocoa doesn’t just randomly send out notifications to test you, they’re coming from somewhere.

What are object and keyPath which you don’t expect them to be?

Are you getting the warning anywhere in your debug logs that an object was deallocated whilst still having KVO notifications registered on it? That explicitly tells you that the KVO notifications can get attached to the wrong object.

_______________________________________________

Cocoa-dev mailing list (Cocoa-***@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/gegs%40ml-in.narkive.net

This email sent to geg

Post by Carl Hoefs
I will set 'context' and use it in my check instead.

Yup, use the context to decide whether to call super *and return* but nothing else. Once you get past that check, don’t call super.

Post by Carl Hoefs
It appears that for some odd reason, once in a blue moon, 'object' and 'keyPath' aren't what they're supposed to be,

It’s not odd, if they’re the object and keyPath of a different observation registered by a superclass of your class. You’ve proved it happens!

_______________________________________________

Cocoa-dev mailing list (Cocoa-***@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/gegs%40ml-in.narkive.net

This email sent

Post by Quincey Morris

Post by Carl Hoefs
I will set 'context' and use it in my check instead.

Yup, use the context to decide whether to call super *and return* but nothing else. Once you get past that check, don’t call super.

Post by Carl Hoefs
It appears that for some odd reason, once in a blue moon, 'object' and 'keyPath' aren't what they're supposed to be,

It’s not odd, if they’re the object and keyPath of a different observation registered by a superclass of your class. You’ve proved it happens!

Well no he hasn’t - because if it was the object and keyPath of a different observation registered by a superclass of his class then passing it to super would allow that class to handle it, which it would do, and there would not be a crash. So it’s not that.
_______________________________________________

Cocoa-dev mailing list (Cocoa-***@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/gegs%40ml-in.narkive.net

This email sent to ***@ml-in.narkive.n

Post by Roland King
Well no he hasn’t

Correct … no he hasn’t. I mis-edited a longer draft of the post.

Post by Roland King
[uploadQueue addOperation:opn]; <-- Thread 1, EXC_BAD_ADDRESS (code=1, address=0xc)
(lldb) po uploadQueue
<NSOperationQueue: 0x17e76d20>{name = 'Upload Queue'}
(lldb) po opn
<NSInvocationOperation: 0x17de5890>
(lldb) bt
* thread #1: tid = 0x207807, 0x204e3a86 libobjc.A.dylib`objc_msgSend + 6, stop reason = EXC_BAD_ACCESS (code=1, address=0xc)
frame #0: 0x204e3a86 libobjc.A.dylib`objc_msgSend + 6
frame #1: 0x2151e27e Foundation`-[NSObject(NSKeyValueObservingPrivate) _changeValueForKeys:count:maybeOldValuesDict:usingBlock:] + 278
frame #2: 0x214822d0 Foundation`-[NSObject(NSKeyValueObservingPrivate) _changeValueForKey:key:key:usingBlock:] + 68

It’s in the middle of handling a change notification. I’d suggest setting a breakpoint at the top of your ‘observeValueForKeyPath:…’ method.

_______________________________________________

Cocoa-dev mailing list (Cocoa-***@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/gegs%40ml-in.

Post by Quincey Morris

Post by Roland King
Well no he hasn’t

Correct … no he hasn’t. I mis-edited a longer draft of the post.

It’s in the middle of handling a change notification. I’d suggest setting a breakpoint at the top of your ‘observeValueForKeyPath:…’ method.

Hmm, I think I may see what the problem is. I assumed -dismissViewControllerAnimated: would end up invoking -prepareForSegue: but it doesn't, so my -removeObserver: call never got invoked. So when transitioning to another ViewController, it would still KVO notify the original VC which was no longer being presented.

Adding -removeObserver: to both places seems to have solved this.
-Carl

_______________________________________________

Cocoa-dev mailing list (Cocoa-***@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/gegs%40ml-in.narkive.net

This email sent

Post by Quincey Morris

Post by Carl Hoefs
I will set 'context' and use it in my check instead.

Yup, use the context to decide whether to call super *and return* but nothing else. Once you get past that check, don’t call super.

Post by Carl Hoefs
It appears that for some odd reason, once in a blue moon, 'object' and 'keyPath' aren't what they're supposed to be,

It’s not odd, if they’re the object and keyPath of a different observation registered by a superclass of your class. You’ve proved it happens!

Now that I've changed things over to use the context value, I get this at the moment I add an NSOperation to the NSOperationQueue:

[uploadQueue addOperation:opn]; <-- Thread 1, EXC_BAD_ADDRESS (code=1, address=0xc)

(lldb) po uploadQueue
<NSOperationQueue: 0x17e76d20>{name = 'Upload Queue'}

(lldb) po opn
<NSInvocationOperation: 0x17de5890>

(lldb) bt
* thread #1: tid = 0x207807, 0x204e3a86 libobjc.A.dylib`objc_msgSend + 6, stop reason = EXC_BAD_ACCESS (code=1, address=0xc)
frame #0: 0x204e3a86 libobjc.A.dylib`objc_msgSend + 6
frame #1: 0x2151e27e Foundation`-[NSObject(NSKeyValueObservingPrivate) _changeValueForKeys:count:maybeOldValuesDict:usingBlock:] + 278
frame #2: 0x214822d0 Foundation`-[NSObject(NSKeyValueObservingPrivate) _changeValueForKey:key:key:usingBlock:] + 68
frame #3: 0x2152f760 Foundation`__addOperations + 1528
* frame #4: 0x000ac9b4 iApp`-[AppSetupConfigViewController saveAppSettings:](self=0x17ed4e20, _cmd="saveAppSettings:", sender=0x17ed2200) + 5776 at AppSetupConfigViewController.m:275
frame #5: 0x25322520 UIKit`-[UIApplication sendAction:to:from:forEvent:] + 80
frame #6: 0x253224b0 UIKit`-[UIControl sendAction:to:forEvent:] + 64
frame #7: 0x2530a3ea UIKit`-[UIControl _sendActionsForEvents:withEvent:] + 466
frame #8: 0x25321dd0 UIKit`-[UIControl touchesEnded:withEvent:] + 616
frame #9: 0x25321a3e UIKit`-[UIWindow _sendTouchesForEvent:] + 646
frame #10: 0x2531a3c6 UIKit`-[UIWindow sendEvent:] + 642
frame #11: 0x252eac84 UIKit`-[UIApplication sendEvent:] + 204
frame #12: 0x252e9228 UIKit`_UIApplicationHandleEventQueue + 5016
frame #13: 0x20cdba66 CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 14
frame #14: 0x20cdb656 CoreFoundation`__CFRunLoopDoSources0 + 454
frame #15: 0x20cd99be CoreFoundation`__CFRunLoopRun + 806
frame #16: 0x20c28288 CoreFoundation`CFRunLoopRunSpecific + 516
frame #17: 0x20c2807c CoreFoundation`CFRunLoopRunInMode + 108
frame #18: 0x22244af8 GraphicsServices`GSEventRunModal + 160
frame #19: 0x253532c4 UIKit`UIApplicationMain + 144
frame #20: 0x000c86c6 iApp`main(argc=1, argv=0x00327bd4) + 122 at main.m:14
(lldb)

-Carl

_______________________________________________

Cocoa-dev mailing list (Cocoa-***@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/gegs%40ml-in.n

Post by Carl Hoefs

Post by Quincey Morris

Post by Carl Hoefs
I will set 'context' and use it in my check instead.

Yup, use the context to decide whether to call super *and return* but nothing else. Once you get past that check, don’t call super.

Post by Carl Hoefs
It appears that for some odd reason, once in a blue moon, 'object' and 'keyPath' aren't what they're supposed to be,

It’s not odd, if they’re the object and keyPath of a different observation registered by a superclass of your class. You’ve proved it happens!

[uploadQueue addOperation:opn]; <-- Thread 1, EXC_BAD_ADDRESS (code=1, address=0xc)
(lldb) po uploadQueue
<NSOperationQueue: 0x17e76d20>{name = 'Upload Queue'}
(lldb) po opn
<NSInvocationOperation: 0x17de5890>
(lldb) bt
* thread #1: tid = 0x207807, 0x204e3a86 libobjc.A.dylib`objc_msgSend + 6, stop reason = EXC_BAD_ACCESS (code=1, address=0xc)
frame #0: 0x204e3a86 libobjc.A.dylib`objc_msgSend + 6
frame #1: 0x2151e27e Foundation`-[NSObject(NSKeyValueObservingPrivate) _changeValueForKeys:count:maybeOldValuesDict:usingBlock:] + 278
frame #2: 0x214822d0 Foundation`-[NSObject(NSKeyValueObservingPrivate) _changeValueForKey:key:key:usingBlock:] + 68
frame #3: 0x2152f760 Foundation`__addOperations + 1528
* frame #4: 0x000ac9b4 iApp`-[AppSetupConfigViewController saveAppSettings:](self=0x17ed4e20, _cmd="saveAppSettings:", sender=0x17ed2200) + 5776 at AppSetupConfigViewController.m:275
frame #5: 0x25322520 UIKit`-[UIApplication sendAction:to:from:forEvent:] + 80
frame #6: 0x253224b0 UIKit`-[UIControl sendAction:to:forEvent:] + 64
frame #7: 0x2530a3ea UIKit`-[UIControl _sendActionsForEvents:withEvent:] + 466
frame #8: 0x25321dd0 UIKit`-[UIControl touchesEnded:withEvent:] + 616
frame #9: 0x25321a3e UIKit`-[UIWindow _sendTouchesForEvent:] + 646
frame #10: 0x2531a3c6 UIKit`-[UIWindow sendEvent:] + 642
frame #11: 0x252eac84 UIKit`-[UIApplication sendEvent:] + 204
frame #12: 0x252e9228 UIKit`_UIApplicationHandleEventQueue + 5016
frame #13: 0x20cdba66 CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 14
frame #14: 0x20cdb656 CoreFoundation`__CFRunLoopDoSources0 + 454
frame #15: 0x20cd99be CoreFoundation`__CFRunLoopRun + 806
frame #16: 0x20c28288 CoreFoundation`CFRunLoopRunSpecific + 516
frame #17: 0x20c2807c CoreFoundation`CFRunLoopRunInMode + 108
frame #18: 0x22244af8 GraphicsServices`GSEventRunModal + 160
frame #19: 0x253532c4 UIKit`UIApplicationMain + 144
frame #20: 0x000c86c6 iApp`main(argc=1, argv=0x00327bd4) + 122 at main.m:14
(lldb)

2016-05-10 16:58:36.066 iApp[2549:2131821] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: '(
"<UITextTapRecognizer: 0x175bb470; state = Possible; delaysTouchesEnded = NO; view = <UITextField 0x175b3410>; target= <(action=oneFingerDoubleTap:, target=<UITextInteractionAssistant 0x175bb3f0>)>; numberOfTapsRequired = 2>",
"<UITapAndAHalfRecognizer: 0x175bb810; state = Possible; view = <UITextField 0x175b3410>; target= <(action=tapAndAHalf:, target=<UITextInteractionAssistant 0x175bb3f0>)>>",
"<UITextTapRecognizer: 0x176c9d90; state = Possible; delaysTouchesEnded = NO; view = <UITextField 0x175b3410>; target= <(action=oneFingerTap:, target=<UITextInteractionAssistant 0x175bb3f0>)>>",
"<UIVariableDelayLoupeGesture: 0x175bbce0; state = Possible; delaysTouchesEnded = NO; view = <UITextField 0x175b3410>; target= <(action=loupeGesture:, target=<UITextInteractionAssistant 0x175bb3f0>)>>"
): An -observeValueForKeyPath:ofObject:change:context: message was received but not handled.
Key path: operations
Observed object: <NSOperationQueue: 0x175464f0>{name = 'Upload Queue'}
Change: {
kind = 1;
}
Context: 0x1c7bb0'
*** First throw call stack:
(0x20d19b8b 0x204d6dff 0x20d19ad1 0x2151cd7d 0x214a3d81 0x21482fe3 0x21482c3b 0x2151e311 0x214822d1 0x2152f761 0xf89b5 0x25322521 0x253224b1 0x2530a3eb 0x25321dd1 0x25321a3f 0x2531a3c7 0x252eac85 0x252e9229 0x20cdba67 0x20cdb657 0x20cd99bf 0x20c28289 0x20c2807d 0x22244af9 0x253532c5 0x1146c7 0x208d4873)
libc++abi.dylib: terminating with uncaught exception of type NSException

BTW, if I remove the addObserver code, this doesn't happen.
-Carl

_______________________________________________

Cocoa-dev mailing list (Cocoa-***@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/gegs%40ml-in.narkive.net

This email sent to

Post by Carl Hoefs
2016-05-10 16:58:36.066 iApp[2549:2131821] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: '(
"<UITextTapRecognizer: 0x175bb470; state = Possible; delaysTouchesEnded = NO; view = <UITextField 0x175b3410>; target= <(action=oneFingerDoubleTap:, target=<UITextInteractionAssistant 0x175bb3f0>)>; numberOfTapsRequired = 2>",
"<UITapAndAHalfRecognizer: 0x175bb810; state = Possible; view = <UITextField 0x175b3410>; target= <(action=tapAndAHalf:, target=<UITextInteractionAssistant 0x175bb3f0>)>>",
"<UITextTapRecognizer: 0x176c9d90; state = Possible; delaysTouchesEnded = NO; view = <UITextField 0x175b3410>; target= <(action=oneFingerTap:, target=<UITextInteractionAssistant 0x175bb3f0>)>>",
"<UIVariableDelayLoupeGesture: 0x175bbce0; state = Possible; delaysTouchesEnded = NO; view = <UITextField 0x175b3410>; target= <(action=loupeGesture:, target=<UITextInteractionAssistant 0x175bb3f0>)>>"
): An -observeValueForKeyPath:ofObject:change:context: message was received but not handled.
Key path: operations
Observed object: <NSOperationQueue: 0x175464f0>{name = 'Upload Queue'}
Change: {
kind = 1;
}
Context: 0x1c7bb0'
(0x20d19b8b 0x204d6dff 0x20d19ad1 0x2151cd7d 0x214a3d81 0x21482fe3 0x21482c3b 0x2151e311 0x214822d1 0x2152f761 0xf89b5 0x25322521 0x253224b1 0x2530a3eb 0x25321dd1 0x25321a3f 0x2531a3c7 0x252eac85 0x252e9229 0x20cdba67 0x20cdb657 0x20cd99bf 0x20c28289 0x20c2807d 0x22244af9 0x253532c5 0x1146c7 0x208d4873)
libc++abi.dylib: terminating with uncaught exception of type NSException
BTW, if I remove the addObserver code, this doesn't happen.
-Carl

Rather hard to tell but that seems to be hinting that the object not handling the KVO is a UITextTapRecognizer. But that may just be an artefact of what’s getting printed out.

But I’ll ask the question I asked earlier

"Are you getting the warning anywhere in your debug logs that an object was deallocated whilst still having KVO notifications registered on it? That explicitly tells you that the KVO notifications can get attached to the wrong object.”.

because it looks here as if something was deallocated with KVO still attached to it and now your KVO calls are going somewhere incorrect.

_______________________________________________

Cocoa-dev mailing list (Cocoa-***@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/gegs%40ml-in.narkive.net

This email sent to ***@ml-in.n

Post by Roland King

Yes, I think it's because I didn't remove the observation when segueing to another VC.
-Carl

_______________________________________________

Cocoa-dev mailing list (Cocoa-***@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/gegs%40ml-in.narkive.net

This e