CBLModel has trouble with dynamic properties in Swift classes

[24601]

Just updated to the current master build of couchbase-lite-ios from my previous known-good-in-my-app version built on Feb 27 and launching the app causes this error.

I have an class named VTCase, of course, with a property caseName which is an NSString (Swift project), @NSManaged property, of course, displaying this object in a form and loading that view controller tries to access this property and this is where it croaks.

Going back to the Feb 27 build of the library fixes the problem.

Swift 1.2 project with Xcode 6.3 6D543q on OS x 10.10.3 (14D130a).

23:54:38.118| WARNING: MYDynamicObject: VTCase.caseName has type @ which is not a known class or protocol
23:54:38.119| WARNING: Dynamic property VTCase.caseName has type '@' unsupported by VTCase
2015-04-07 23:54:38.119 Voltaire[49935:1641226] -[VTCase caseName]: unrecognized selector sent to instance 0x788a72f0

[snej]

Let's see. The last commit to MYDynamicObject was on Feb 19, but it didn't get merged into CBL until March 12 (commit 82ec99c).

That commit affected property type parsing, to handle protocol types, but I'm surprised it would break with a common type like NSString — our unit tests would have caught that. Unless there's something weird about the property type encoded by Swift.

[snej]

Fixed — for some reason the property type got encoded as id not NSString, and that MYDynamicObject change broke support for such properties.

[24601]

Jens,

Thank you so much, again! Will pull and rebuild and try again!

Cheers!

Basit

[24601]

@snej - Just pulled the latest version from master and built it and still seem to be getting the issue (al beit without the MYDynamicObject warning line):

19:45:35.726| WARNING: Dynamic property VTCase.caseName has type '@' unsupported by VTCase
2015-04-08 19:45:35.727 Voltaire[13066:128226] -[VTCase caseName]: unrecognized selector sent to instance 0x7afdb8b0
(lldb) bt
* thread #1: tid = 0x1f4e2, 0x04caa69a libsystem_kernel.dylib`__pthread_kill + 10, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
    frame #0: 0x04caa69a libsystem_kernel.dylib`__pthread_kill + 10
    frame #1: 0x04cd8f19 libsystem_pthread.dylib`pthread_kill + 101
    frame #2: 0x04a61a5a libsystem_sim_c.dylib`abort + 156
    frame #3: 0x00360f97 Voltaire`uncaught_exception_handler + 38
    frame #4: 0x00361443 Voltaire`-[APLPLCrashReporter handleException:] + 17
  * frame #5: 0x002e5b79 Voltaire`-[APLCrashController handleException:](self=0x7aee95c0, _cmd=0x089bdd41, exception=0x7aff2570) + 81 at APLCrashController.m:73
    frame #6: 0x002daa69 Voltaire`-[APLCurrentSession applicationCrahsedWithHighLevelException:](self=0x7aee60b0, _cmd=0x00397887, notification=0x7bda1650) + 247 at APLCurrentSession.m:196
    frame #7: 0x026b8079 Foundation`__57-[NSNotificationCenter addObserver:selector:name:object:]_block_invoke + 40
    frame #8: 0x040b5be4 CoreFoundation`__CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 20
    frame #9: 0x03fa211b CoreFoundation`_CFXNotificationPost + 3051
    frame #10: 0x026a75d6 Foundation`-[NSNotificationCenter postNotificationName:object:userInfo:] + 98
    frame #11: 0x002ef28e Voltaire`APLInternalUncaughtExceptionHandler(exception=0x7aff2570) + 218 at APLInternalLogger.m:30
    frame #12: 0x040ebb80 CoreFoundation`__handleUncaughtException + 832
    frame #13: 0x03d74d3d libobjc.A.dylib`_objc_terminate() + 100
    frame #14: 0x04878cf0 libc++abi.dylib`std::__terminate(void (*)()) + 14
    frame #15: 0x04878922 libc++abi.dylib`__cxa_rethrow + 103
    frame #16: 0x03d74c38 libobjc.A.dylib`objc_exception_rethrow + 47
    frame #17: 0x04001b2d CoreFoundation`CFRunLoopRunSpecific + 653
    frame #18: 0x0400188b CoreFoundation`CFRunLoopRunInMode + 123
    frame #19: 0x0824c2c9 GraphicsServices`GSEventRunModal + 192
    frame #20: 0x0824c106 GraphicsServices`GSEventRun + 104
    frame #21: 0x01182106 UIKit`UIApplicationMain + 1526
    frame #22: 0x00117a74 Voltaire`main + 180 at AppDelegate.swift:23
    frame #23: 0x049bdac9 libdyld.dylib`start + 1
(lldb) 

[24601]

And, the nuance now with the released version of Xcode 6.3 is that with Swift 1.2 nullability modifiers, reverting to Feb 27 known-good does not work since those builds error out with nullability errors (that the newer builds do not suffer from, of course even in Xcode 6.3 betas these weren't an issue, only with the GM release today has that become an issue, so kind of between a rock and a hard place, happy to help with diagnosing this further as you need!

[snej]

Looks like CBLModel's +impForGetterOfProperty: (and ...setter... too probably) need to check for NSObject as the property class. It's weird that this didn't trigger in the unit tests after I added an id-valued property, though...

[24601]

Thank you, @snej, as myself and my team gain more experience with CBL we look forward to being able to help and be more self-sufficient on diagnosis and fix of these issues, much rather have us come with a PR for you than just an "ugh, this is broken" issue!

[snej]

No problem. MYDynamicObject is some really weird low-level stuff; definitely not one of the more approachable parts of the source code! Thanks a lot for working with the master branch — it really helps us find problems before we release.

[24601]

You are absolutely welcome, @snej - if that's the little we can do to contribute for now/until we can learn the intricacies of the code, happy to be able to do it (we are meticulous about keeping known-good-to-us/for-our-use-case binaries for use just in situations like this, although with the nullability issue with Swift 1.2 release, it's actually forced us to revert to the Xcode-beta for development so we can use the older known-good binary until this is fixed, hopefully the expiration date of the beta is still a ways out - that makes me nervous, though!).

[24601]

Hi! With a bit of guidance on exactly what to work on in CBLModel's +impForGetterOfProperty (and setter?) I am happy to try and work on a fix for this!

[snej]

Thanks! The code in those methods should treat [NSObject class] as equivalent to Nil when testing propertyClass. See if that fixes your problem. (Sorry, I've been working on a branch for the past week and haven't gotten around to checking out master and making this change.)

[24601]

Sure, I absolutely understand and want to help and not just complain "hey! it's broken!", so I'll give it a shot later today or tomorrow and report back with (hopefully?) a PR or my hands up :).

[24601]

Been spending a fair amount of time playing in these methods and can't seem to get things to work.

Been doing things like:

1. adding

else if ( [propertyClass isSubclassOfClass: [NSObject class]])
{
return [super impForGetterOfProperty: property ofClass: propertyClass];
}

right before the last catch-all else in the getter method but property fields of CBLModel subclasses still seem to be broken...

2. Doing commensurate updates on the setter side

Still playing, any pseudocode or explanation could be helpful, still working with this....

[24601]

(On these properties, for example, I'm getting similar errors to earlier like:)

WARNING: MYDynamicObject: VTCase.currentReport has type @"VTJuryReport" which is not a known class or protocol

[24601]

Should I be looking into why the error messages have quoted string with Obj-c style strings?

For example, calling MYDynamicObject, if we're looking for class (klass as in the code added on the Feb 19 commit) is looking for an actual class named '!@"VTJuryReport"', it certainly won't find it b/c of the @" preceding it and " suffix on it, is this an issue? Is there some string handling nuance between Swift-ObjC that could be the issue here?

11:27:58.403| WARNING: MYDynamicObject: VTCase.currentReport has type @"VTJuryReport" which is not a known class or protocol
11:27:58.403| WARNING: Dynamic property VTCase.currentReport has type '@"VTJuryReport"' unsupported by VTCase

[24601]

Hmmmmm, looks like, at least for the previous two issues I've been grappling with, that the issue was a missing @objc(VTJuryReport) declaration in the Swift file.

Doing some testing to see if my fix works....

[24601]

Submitted PR above

[24601]

Improved fix based on my own commentary on the original PR after thinking about a better/cleaner/more maintainable way of doing/implementing this.

[snej]

Can you show me a minimal test case that reproduces the problem? Re-reading this thread, I'm not clear on what is still going wrong after my initial fix.

[24601]

Absolutely, @snej - it happens whenever trying to access a property on a CBLModel.

Here's a minimal test case that demonstrates the issue, launch the app, create a record, and then try to view it, should crash with the trace in the README on the repo:

https://github.com/24601/CBL-Bug-Demo