Backendless Crashing (iOS SDK)

iOS
21

Hi again,

attached are the details for the testing an some notes and suggestions … please do let me know if you need further info

crashDetails.pdf (54.9 KB)

22

Hello @eyad-pro,

Many thanks for your detailed description.
One more thing.
Could you please provide the code sample of how do you call those find methods?
Do you use the different DispatchQueue.global(qos: .background).async for each find method or these methods are called together in one queue?

Regards,
Olha

23

Hi Olha,

each one separately inside :

dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0)

24

Thanks,

I was able to reproduce this issue.
As far as the Swift-SDK is not designed to support multithreading requests, the EXC_BAD_ACCESS error occurs when you’re trying to write the results of 3 different requests (objectIds of the found objects) in one variable (storedObjects) at the same time. And when the results are received separately with a little delay no prolems occure.
The thing I can suggest is to make a little delay between those find requests to make it work.

I’ve added the delay and no errors occure:

double delayInSeconds = 0.001;
dispatch_time_t popTime = dispatch_time(DISPATCH_TIME_NOW, delayInSeconds * NSEC_PER_SEC);

dispatch_after(popTime, dispatch_get_main_queue(), ^(void){
	dispatch_async(dispatch_get_global_queue( DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^(void) {
    	// first find func
    });
});

dispatch_after(popTime, dispatch_get_main_queue(), ^(void){
	dispatch_async(dispatch_get_global_queue( DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^(void) {
    	// second find func
    });
});

dispatch_after(popTime, dispatch_get_main_queue(), ^(void){
	dispatch_async(dispatch_get_global_queue( DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^(void) {
    	// third find func
    });
});

Regards,
Olha

25

Hi…

Thanks this was around my suspicion too …I’'l try than and let you know if anything

26

Hi…

unfortunately its still crashing … less number of times though, but still happing … but first I have a comment on the above approach

Maybe I missing something here, but we are introducing delays in firing requests to the server to avoid collisions , but still will not prevent collisions from happening on the receiving side … I mean clearly we can differentiate the time in sending but in receiving (due to network delays), they actually can be received at the same Time, now will this cause a crash ?..

sorry but is there anything I’m missing here ?

27

Hello,

sorry, if my answer confused you. Yes, if we receive several responses at the same time it may cause a crash. The only way here I see now is to organise requests for retrieving the responses one by one to avoid the concurrent access to the variable.

Regards,
Olha

28

thanks …

this means the only way to be sure is to actually send them serially , correct ?

29

Yes

Regards, Dima

30

Thanks for the clarification …

But as a user feedback, this seems to be a big deal which need addressing in future releases …concurrent APIs are vey much common for many reasons

Thanks
Eyad

31

We will discuss this with the development team.
Thank you for feedback, and we really appreciate it.

Regards, Dima

32

Thanks !

33

Hi…

Sorry I thought you need to know about the below further testing and conclusions:

I created a sample project with the required functions to test two scenarios only

– Firing all APIs at once on the main queue : dispatch_async(dispatch_get_main_queue()

– Firing all APIs at once on a background queue: dispatch_async(dispatch_get_global_queue

the findings are simply as expected … the main queue scenarios went fine even with lots of testing and so much concurrent API calls ( more than 10 calls at once) … while on the background queue it did crash in like 10%-20% of the times…

the conclusion , apparently its not that SDK is no thread safe … its the mismatch between the main and background queues since most of the issues related to the background queues in this case are because on releasing objects by a certain queue while the other queue still need it …

Just wanted to highlight this so you have a better chance in solving it …in my case, Ill do some tweaks to have backendless APIs outside the background queues
for the time being

34

Hi,

This issue is fixed. Could you please try with Swift-SDK v6.2.7?

Regards,
Olha

35

Hi Olha,

Thanks for following up on this important issue . I will test the above Swift-SDK 6.2.7…in the coming days . As of my existing project , I have moved all API calls on the main thread and everything seem fine (no crashes)

thanks again

Regards
Eyad

1 Like