BackendlessUser Objects randomly crash app when trying to access email address property

barry-kostjens · March 7, 2016, 8:30am

Swift / iOS 9.2:
I have got some strange behavior with the code below. It fetches all groups, then imports all users related to that group. BLGroup ->> (One to Many) BackendlessUser
In the code below I removed all core data calls, it’s just to demo where / when the app crashes
Currently this crashes on line 10, but not for the first group. The first group outputs (prints email address) its users correctly, however when looping the second group the app crashes with:
-[NSNull length]: unrecognized selector sent to instance 0x109175af0
This did not happen on friday, everything worked -> weekend I had off, no code changes -> this morning I run the app the first time: Crashes. Just as a note: I also had this last week, after waiting for several hours all worked again. I didn’t report it back then as I was busy with other support tickets and I didn’t want to create too much of them at once.
If you need more info, please let me know.


private func importGroups() {
 
 func importGroup(group:BLGroup) {
 
 let backendID = group.objectId!
 let name = group.name!
 
 for user in group.users {
 print ("User: \(user.email)")
 }
 }
 
 let query = BackendlessDataQuery()
 query.whereClause = "users.email = '\(backendless.userService.currentUser.email)'"
 
 let dataStore = backendless.data.of(BLGroup.ofClass())
 
 dataStore.find(
 query,
 response: {(bc : BackendlessCollection!) -> () in
 let groups = bc.getCurrentPage() as! [BLGroup]
 
 // import groups
 for group in groups {
 importGroup(group)
 }
 },
 error: { (fault : Fault!) -> () in
 print("Server reported an error (ASYNC): \(fault)")
 })
 }

Stack:


*** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[NSNull length]: unrecognized selector sent to instance 0x111285af0'
*** First throw call stack:
(
	0   CoreFoundation                      0x0000000111060e65 __exceptionPreprocess + 165
	1   libobjc.A.dylib                     0x0000000110ad1deb objc_exception_throw + 48
	2   CoreFoundation                      0x000000011106948d -[NSObject(NSObject) doesNotRecognizeSelector:] + 205
	3   CoreFoundation                      0x0000000110fb690a ___forwarding___ + 970
	4   CoreFoundation                      0x0000000110fb64b8 _CF_forwarding_prep_0 + 120
	5   libswiftCore.dylib                  0x0000000111e852f3 _TTSf4g_d___TFSSCfMSSFT12_cocoaStringPSs9AnyObject__SS + 131
	6   libswiftCore.dylib                  0x0000000111e4c9c3 _TFSSCfMSSFT12_cocoaStringPSs9AnyObject__SS + 19
	7   libswiftFoundation.dylib            0x0000000112233260 _TF10Foundation24_convertNSStringToStringFGSqCSo8NSString_SS + 16
	8   ProProject                          0x000000010cd4ad6d _TFFC10ProProject22BackendlessUserManagerP33_4294ECCEE85D050961C84ABEF70E804F12importGroupsFS0_FT_T_L_11importGroupfCS_7BLGroupT_ + 1885
	9   ProProject                          0x000000010cd4ba09 _TFFC10ProProject22BackendlessUserManagerP33_4294ECCEE85D050961C84ABEF70E804F12importGroupsFS0_FT_T_U_FGSQCSo21BackendlessCollection_T_ + 1033
	10  ProProject                          0x000000010ccbc5a7 _TTRXFo_oGSQCSo21BackendlessCollection__dT__XFo_iGSQS___iT__ + 23
	11  ProProject                          0x000000010cd48cf1 _TPA__TTRXFo_oGSQCSo21BackendlessCollection__dT__XFo_iGSQS___iT__ + 81
	12  ProProject                          0x000000010ccbc5e0 _TTRXFo_iGSQCSo21BackendlessCollection__iT__XFo_oGSQS___dT__ + 32
	13  ProProject                          0x000000010ccbc628 _TTRXFo_oGSQCSo21BackendlessCollection__dT__XFdCb_dGSQS___dT__ + 56
	14  ProProject                          0x000000010ce53ac4 -[ResponderBlocksContext responseHandler:] + 52
	15  ProProject                          0x000000010ce53276 -[Responder responseHandler:] + 262
	16  ProProject                          0x000000010ce532b1 -[Responder responseHandler:] + 321
	17  ProProject                          0x000000010ce13c98 -[HttpEngine processAsyncAMFResponse:] + 2616
	18  ProProject                          0x000000010ce15b5a __41-[HttpEngine connectionDidFinishLoading:]_block_invoke + 42
	19  libdispatch.dylib                   0x000000011240ee5d _dispatch_call_block_and_release + 12
	20  libdispatch.dylib                   0x000000011242f49b _dispatch_client_callout + 8
	21  libdispatch.dylib                   0x00000001124172af _dispatch_main_queue_callback_4CF + 1738
	22  CoreFoundation                      0x0000000110fc0d09 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 9
	23  CoreFoundation                      0x0000000110f822c9 __CFRunLoopRun + 2073
	24  CoreFoundation                      0x0000000110f81828 CFRunLoopRunSpecific + 488
	25  GraphicsServices                    0x00000001134bfad2 GSEventRunModal + 161
	26  UIKit                               0x000000010d523610 UIApplicationMain + 171
	27  ProProject                          0x000000010ccef5ad main + 109
	28  libdyld.dylib                       0x000000011246392d start + 1
	29  ???                                 0x0000000000000001 0x0 + 1
)
libc++abi.dylib: terminating with uncaught exception of type NSException

mark-piller · March 7, 2016, 12:36pm

Hi Barry,

Could you please check which line results in error? Line 10 you pointed out does not have any code.

Mark

barry-kostjens · March 7, 2016, 12:37pm

Sorry, while editing it was line 10, now it’s line 9.

mark-piller · March 7, 2016, 12:53pm

Could you please email your APP ID and IOS SECRET KEY to support@backendless.com? We’d like to run that code in our environment against your backend.

Regards,
Mark

barry-kostjens · March 7, 2016, 1:07pm

Done, thanks a lot again!

barry-kostjens · March 7, 2016, 2:20pm

By the way: I suspect that autoloading is causing this issue…

Im gonna try to prevent using autoloading and will report back.

barry-kostjens · March 7, 2016, 2:26pm

Yup, that fixed it!

disabled autoloading of users in the BLGroup entity.
added related queryOption.

Runs fine now. So it is definitely caused by using autoloading of relations.

For me: No problem: I won’t use autoloading anymore.

vyacheslav-vdovichenko · March 7, 2016, 4:37pm

All right, Barry,

Group.users is 1:N relation, so if autoload for it is off then BackendlessCollection contains BLGroup objects with users == nil.

I modified the function to be aware of the use–case:

func importGroup(group:BLGroup) {
let backendID = group.objectId!
let name = group.name!
if group.user != nil {
for user in group.users {
print ("User: \(user.email)")
}
}
}

barry-kostjens · March 8, 2016, 8:12am

Hi Vyacheslav,

The problem is: Autoload does not function correctly. Im now not using it anymore as it gives random problems like mentioned in this topic. ‘users’ should never be nil when using autoloading, but at random days/times they are nil. I know that I can do a check on them to see if they are nil, but that is not the point: I need the users in that group. Only solution at the moment is not using autoloading but using queryOption the fetch the relations. No problem for me, but it should be fixed on your side as other customers will have the same problem.

mark-piller · March 8, 2016, 8:15am

Barry,

The only time when a related property may be nil is when there is no related object assigned at the persistence (database) level.

Regards,
Mark

barry-kostjens · March 8, 2016, 8:40am

Exactly Mark,

But the problem is: they are nil while they are related.

Again; for me no problem as Im not using autoloading anymore, but other users will suffer from the same bug.

You can close this if you want: but again: others will run into the same problem if this isn’t fixed.

mark-piller · March 8, 2016, 8:48am

The challenge for fixing something is being able to reproduce it. All our tests for relations pass and no one else has reported the same problem (a lot of other people use relation auto-loading). If you do not mind running export on your data (with schema) and emailing the export file (or just a public link to it) to support@backendless.com, it will make it easier for us to reproduce the problem internally.

Regards,
Mark

barry-kostjens · March 8, 2016, 8:55am

Ok, I just sent you the email

mark-piller · March 8, 2016, 9:24am

Thanks, Barry. I was able to duplicate the problem. The bug is not on the server-side, but actually is in the SDK. I’ll create an internal trouble ticket for it.

I also noticed that your schema has a circular dependency. BLGroup has a 1:N relation with Users. And Users has a 1:N relation with BLGroup. Is this by design?

Regards,
Mark

barry-kostjens · March 8, 2016, 9:45am

Hi Mark,

Correct Users <<- Many to Many ->> Groups, this is by design.

vyacheslav-vdovichenko · April 15, 2016, 9:04am

We’ve fixed this issue, you could update latest Backendless SDK from CocoaPods (3.0.15 release) or from github (CommLibiOS & backendless).

barry-kostjens · April 15, 2016, 10:18am

Thanks a lot!

david-zamani-kord · April 15, 2016, 4:40pm

I don’t know if it’s the same problem but since I tried to use this new release I got random crash but with too few information on the cause.

vyacheslav-vdovichenko · April 15, 2016, 7:05pm

I checked YOUR BLGroup and importGroup func - and it works fine with latest release. Please provide a sample code, which is crashing.

jovan-jovanovic · August 7, 2016, 10:55pm

Greetings folks,

I’ve just started using Backendless and I have a similar problem. I’m using loginWithFacebookSDK function and trying to access user’s “name” property. I’m using iOS 9.3 simulator, Swift SDK. Part of the code looks like this (and the crash is standard “-[NSNull length]: unrecognized selector sent to instance 0x10e7eed80”:

let backendless = Backendless.sharedInstance()

backendless.userService.loginWithFacebookSDK(token, fieldsMapping: fieldsMapping,

    response: { (user: BackendlessUser!) -> Void in

                                

        if user.name.isEmpty {

                                    

            // Continue to setup name

            self.performSegueWithIdentifier(Constants.kLoginViewControllerToLoginNameViewControllerSegue, sender: nil)

        }

        else {

                                    

            // Continue to main screen

            Settings.setUserLoggedIn(true)

            (UIApplication.sharedApplication().delegate as! AppDelegate).userLoggedIn()

        }

    },

    error: { (fault: Fault!) -> Void in

                                

        print("Server reported an error: \(fault)")

    })