When I’m on my Uni network, [backendless.messaging registerForRemoteNotifications] blows up with EXC_BAD_ACCESS originating from HTTPEngine with a final entry at [NSString stringWithFormat]. I suspect it’s because the WiFi network blocks peer-to-peer. I don’t know how to contain this error or workaround it. No crash logs seem to have been generated.
Any suggestions?
Thanks.
Alex,
Just to make sure we’re on the same page, when you reference a “Uni network”, are you talking about this?:
If so, what is the process of setting it up so we can reproduce the problem?
Regards,
Mark
Hi Mark,
Sorry, I just meant university WiFi. Note that things work fine from home WiFi and 3G. I’m happy to try to run any network diagnostic from my end to try to get at the problem.
–Alex
Hi again,
The problem isn’t the network as I’d thought. Backendless standalone CodeRunner and Redis processes were down. Even though <host>/api was still alive, the system was in fact down. Some subsequent error returned to HttpEngine is not being processed correctly via [NSString stringWithFormat].
My question now is what log files can I check to try to understand why CodeRunner went down? How to address this fatal error in HttpEngine? Also, is there another service I can check besides /api to know whether the system is alive?
Happy to call off the dogs regarding the network issue. The server went down at a very strange time and the only difference seemed to be the network.
Thanks,
–Alex
I’ve checked the logs and there was definitely some error activity with Redis and CodeRunner this morning. I attach them here for you review.
Thanks.
–Alex
logs.zip (173.38kB)
Just one final comment. The errors I saw leading to EXC_BAD_ACC were very similar to the ones reported here:
http://support.backendless.com/t/object-saving-crash-in-ios
Namely, a stack trace involving NamedObject and AnonymousObject originating from HttpEngine.
Thanks.
We provide payed support for standalone version. please contact sales@backendless.com to get more info.
Thanks Sergey. This is a FATAL bug in Backendless iOS API. Naturally, since standalone is free, you can choose to address it or not. I’m hoping you care enough about this major problem to take a look at it.
For sure. And I can not reproduce this issue on my own machine. so I suppose that there is some problem with your environment. that is why I suggest you to contact our sales get payed support.
Have you brought Redis and CodeRunner down? I can reproduce this problem 100% by simply bring those two services down and trying to access standalone through the iOS API.
I have built and attached a test project that reproduces the error 100% of the time if I bring Redis and CodeRunner down on my host. Please note the fatal error is in the Backendless client iOS API, not on the server etc…I have left the “lib” file where Backendless APIs would normally go blank in the zip file to save space. You simply need to copy the files into it, etc… You will see my endpoint and Application ID and secret key for the test app I’ve created in the code. I will leave these services down overnight (Aus time), so for the next 12 hours or so.
Given that this is 100% reproducible and the error occurs entirely in the client API, I’m hoping you look at it.
Thanks,
–Alex
RedisDisaster.zip (36.19kB)
when core components of the system are down any other problems you experience on the client side are not problems are simply side effects. Reproducing the error in iOS lib here is pointless since without redis and coderunner the system is dead. It is utterly important to have a monitoring system in place to make sure that all components are operational.
Redis went down, on its own, earlier today, causing this issue. Server components go down, this is a fact of life. But clients should fail gracefully. If a Website is inaccessible, should a client application crash? You can’t possibly be telling me that apps crashing 100% of the time with EXC_BAD_ACC because your client library isn’t able to deal with it is a fact of life Backendless users have to live with??
The fix is done in [ReaderReferenceCache objectKey:], you could check the fixed lib from ios-SDK github. Let us know how it works for you.
In that support ticket a cause of problem was that NSObject “hash” property was overridden. Hope your data model classes don’t have “hash” property?
Hi, thank you very much for working on this. Unfortunately, I’m still getting the same crash with the new lib with the stack trace copied below… (I don’t include all of it to keep it short)
You can reproduce this issue right now by running the below code pointing to my server.
#define BACKENDLESS_APPLICATION_ID @“98E74AEC-BDBE-B9FD-FFAA-FD0B485FAA00”
#define BACKENDLESS_SECRET @“B10FEF97-8D80-F145-FF51-597FAEBC4000”
#define BACKENDLESS_VERSION @“v1”
-
(void)viewDidLoad {
[super viewDidLoad];
backendless.hostURL = @“http://biofeedback.science.uwa.edu.au:8086/api”;
[backendless initApp:BACKENDLESS_APPLICATION_ID secret:BACKENDLESS_SECRET version:BACKENDLESS_VERSION];
[backendless.userService setStayLoggedIn:YES];
Fault* fault;
BackendlessUser* user = [backendless.userService login:@“foo@bar.com” password:@“test1000” error:&fault];
[backendless.messaging registerForRemoteNotifications];
NSLog(@“Got here”);
}
#############################################################################
#0 0x03585781 in szone_malloc_should_clear ()
#10 0x00449c99 in +[NSString stringWithFormat:] ()
#11 0x00133679 in -[ReaderReferenceCache objectKey:] at /Users/slava/Documents/Projects/WebORBiOS/CommLibiOS/weborb/Reader/ReaderReferenceCache.m:59
#12 0x00133724 in -[ReaderReferenceCache hasObject:type:] at /Users/slava/Documents/Projects/WebORBiOS/CommLibiOS/weborb/Reader/ReaderReferenceCache.m:76
#13 0x001336bd in -[ReaderReferenceCache hasObject:] at /Users/slava/Documents/Projects/WebORBiOS/CommLibiOS/weborb/Reader/ReaderReferenceCache.m:67
#14 0x00130d26 in -[ArrayType defaultAdapt:] at /Users/slava/Documents/Projects/WebORBiOS/CommLibiOS/weborb/Reader/ArrayType.m:63
#15 0x0012ffdb in -[AnonymousObject defaultAdapt:] at /Users/slava/Documents/Projects/WebORBiOS/CommLibiOS/weborb/Reader/AnonymousObject.m:303
#16 0x001322e3 in -[NamedObject defaultAdapt:] at /Users/slava/Documents/Projects/WebORBiOS/CommLibiOS/weborb/Reader/NamedObject.m:74
#17 0x0012ffdb in -[AnonymousObject defaultAdapt:] at /Users/slava/Documents/Projects/WebORBiOS/CommLibiOS/weborb/Reader/AnonymousObject.m:303
Yes, we reproduce this issue. We are working with it.
Thank you very much.
Hi Alex,
We have fixed this issue, you should update the latest Backendless SDK via CocoaPods (3.0.30 release) or from ios-SDK github (CommLibiOS & backendless).
Regards,
Slava
Brilliant! I can confirm it’s working from my end. Thanks very much for fixing this so quickly.