Crash while storing an object...

[drdaz7]

Hi there

I'm experiencing a crash outside my code when I try to store one of my 'LocationTime' objects... but only when the set called 'areas' has content.

My LocationTime object looks like this (it's a point in space / time, so resembles a typical location object):

Code: [Select]

@interface LocationTime : NSObject

@property (nonatomic, retain) NSNumber * latitude;
@property (nonatomic, retain) NSNumber * longitude;
@property (nonatomic, retain) NSDate * time;
@property (nonatomic, retain) NSSet *areas;
@property (nonatomic, retain) OfferEvent *offerEvent;
@property (nonatomic, retain) User *user;

-(CLLocation *) getLocation;
-(LocationTime *) initWithLocation:(CLLocation *)location andAreas:(NSSet *)areas;

@end
And the 'Area' objects which I populate the 'area' set with look like this (this is rather like a CLCircularRegion):

Code: [Select]

@interface Area : NSObject

@property (nonatomic, retain) NSNumber * centerLatitude;
@property (nonatomic, retain) NSNumber * centerLongitude;
@property (nonatomic, retain) NSString * displayDescription;
@property (nonatomic, retain) NSNumber * radius;
@property (nonatomic, retain) NSSet *locationTimes;
@property (nonatomic, retain) NSSet *offers;
@property (nonatomic, retain) NSString *identifier;
@end
When I attempt to persist a LocationTime object on FF, it works fine, unless I have 1 or more Area objects in the areas set. In this case it crashes and yields a dump like this:

Code: [Select]

2014-03-17 17:19:27.625 Refresh[49837:60b] -[__NSSetI addObject:]: unrecognized selector sent to instance 0x9f5cf20
<unknown>:0: error: -[FatFractalDataTests testLocationTimeCanBeCreatedAndRetrieved] : -[__NSSetI addObject:]: unrecognized selector sent to instance 0x9f5cf20
(
0   CoreFoundation                      0x01de91e4 __exceptionPreprocess + 180
1   libobjc.A.dylib                     0x01b688e5 objc_exception_throw + 44
2   CoreFoundation                      0x01e86243 -[NSObject(NSObject) doesNotRecognizeSelector:] + 275
3   CoreFoundation                      0x01dd950b ___forwarding___ + 1019
4   CoreFoundation                      0x01dd90ee _CF_forwarding_prep_0 + 14
5   Refresh                             0x00043291 -[FatFractal setValuesOnObject:fromDict:loadFromCacheOnly:doAutoLoadRefs:doAutoLoadBlobs:] + 2027
6   Refresh                             0x000380dc __51-[FatFractal createObj:atUri:onComplete:onOffline:]_block_invoke + 620
7   Refresh                             0x0003199e __102-[FatFractal invokeHttpMethod:body:bodyIsJson:mimeType:onUrl:responseIsJson:customHeaders:onComplete:]_block_invoke + 1525
8   Refresh                             0x0004c9d4 -[FFHttpDelegate connectionDidFinishLoading:] + 86
9   Foundation                          0x01931e49 ___NSURLConnectionDidFinishLoading_block_invoke + 40
10  Foundation                          0x018c87e1 __65-[NSURLConnectionInternal _withConnectionAndDelegate:onlyActive:]_block_invoke + 62
11  Foundation                          0x01750f5e -[NSURLConnectionInternalConnection invokeForDelegate:] + 119
12  Foundation                          0x01750ec6 -[NSURLConnectionInternal _withConnectionAndDelegate:onlyActive:] + 208
13  Foundation                          0x01750dd8 -[NSURLConnectionInternal _withActiveConnectionAndDelegate:] + 76
14  Foundation                          0x01751188 _NSURLConnectionDidFinishLoading + 43
15  CFNetwork                           0x0213d69f ___ZN27URLConnectionClient_Classic26_delegate_didFinishLoadingEU13block_pointerFvvE_block_invoke + 111
16  CFNetwork                           0x0213b3de ___ZN27URLConnectionClient_Classic18_withDelegateAsyncEPKcU13block_pointerFvP16_CFURLConnectionPK33CFURLConnectionClientCurrent_VMaxE_block_invoke_2 + 104

...

It appears that the Area objects get created correctly, but the operation fails at some point after that. Any suggestions would be greatly appreciated.

EDIT: I just tried running this against my local environment, and I can see that the object is actually persisted correctly - the server reports 201, and I can access the object at the URL provided in the server log. So this appears to be an issue with the client.

[gkc]

I will try to reproduce ... From the looks of it, your set of objects is immutable ...

[drdaz7]

Yeah... it's defined as an NSSet. I've tried switching to an NSMutableSet, but I didn't see a change in behaviour.

[gkc]

CoreData?

[gkc]

I'll patch the immediate problem in the next couple of hours

with regards to your data model - do the "areas" have an independent life cycle?

[drdaz7]

I'm migrating away from CoreData actually - there shouldn't be any of it left in this flow. Why do you ask?

Wrt the areas having an independent life cycle, I'm not quite sure what you mean...

[gkc]

Ok am just curious how you've got an __NSSetI instance

Independent life cycle - ie do the area objects have a life of their own (are they created / updated / deleted in their own right, or are they just part of a containing object)

[drdaz7]

Interesting. You've got me curious now too. Part of the migration process I did today involved taking the auto generated CoreData types and changing them to inherit from NSObject instead of NSManagedObject. The 2 objects in question were converted in that way.

It seems odd, since this error comes in the context of an XCTest case where CoreData really isn't involved as far as I can see... Admittedly I haven't unlinked the CoreData library from the project yet, since I'm still using it in one place. There is also no sign of CoreData in the full stack trace.

The areas exist in their own right - although they are always referred to by other objects, but by more than one type of object.

[gkc]

OK

(1) This __NSSetI business is a bit mysterious but let's put that aside for a minute :-)
(2) I've built a patch but am having difficulty uploading at the moment (tethered cell phone) ... will ask a colleague to build & ship to you
(3) Please take a look at https://github.com/FatFractal/fatfractal-code-samples/tree/master/TaggedLocations - shows how to handle situations where you have objects which have sets of references other objects which have their own independent life cycles

[dave]

Hi,

Please see

https://system.fatfractal.com/repo/artifact/Releases/R1.2.2.3/FF_IOS_SDK_R1.2.2.3_R2694.zip

for a new build of the SDK and let us know how it goes!

NOTE: Please always check here for latest releases : http://fatfractal.com/downloads

[drdaz7]

Superb! That did it... Really loving the service level with you guys. You're doing it right.

I still have no clue as to why I've ended up with an NSSetI object though.

Is there any way I can debug this? What does your logic switch on when deciding to create one of these objects vs something else (presumably the NSSet I was expecting)?

[gkc]

The NSSetI object can only have been created by something else. The reason you were having the failure was as follows:
. When creating or updating an object, the resulting state of the object is echoed back from the server. The reason for this is that some server-side code may have modified the object (added some fields, normalised some more, etc etc). That echo is then reflected back into the object. In your case, the object contained an immutable set and the FF de-serialiser was trying to call addObject on it. The patch changed things so that immutable sets (or arrays) will not be updated by the response.

There is no code path through which FF can be creating an instance of __NSSetI in this case

When retrieving, the FF deserialiser will create instances of your classes dynamically; and for example if it needs to deserialise into an NSSet (or NSArray) property which is nil in the newly created instance, then it will create an instance of an NSMutableSet (or NSMutableArray), set that as the relevant property in the containing object, and then call addObject on it

Hope that makes sense ... FYI, we are likely to open-source the iOS SDK (and the Android one) in the next couple of months as they are primarily convenience libraries.

[gkc]

Also ...

Really loving the service level with you guys. You're doing it right.

Thanks!

[drdaz7]

(3) Please take a look at https://github.com/FatFractal/fatfractal-code-samples/tree/master/TaggedLocations - shows how to handle situations where you have objects which have sets of references other objects which have their own independent life cycles

I'm probably just being lazy / obtuse, but which part of that code demonstrates this? Is it the handling of the tag objects?