0

Whenever there is a connection problem, a slow connection on 2G , etc., my app crashes with the following log:

enter image description here

What I can get from the log is, that it crashes on sendSynchronousRequest method of the NSURLConnection. How do I know what exactly is the problem, and how do I solve it? I have put Reachability methods, given by Apple, but the return YES to both Internet reachability and Host reachability. It's just that the internet connection is very slow. On Fast connections (Wifi), it works perfectly well.

Edit:

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
[window setFrame:[[UIScreen mainScreen] bounds]];
NSUserDefaults *defaults = [NSUserDefaults standardUserDefaults];
//singleton
u=[[U5 alloc]init];
m_tUSyncPersistableConfig  = [[USyncPersistableConfig alloc] init] ;    
    m_commonObj = [[CommonClass alloc] init] ;
u.m_tUSyncPersistableConfig=m_tUSyncPersistableConfig;
    u.commonObj = m_commonObj;


 //register for push notifications
   [[UIApplication sharedApplication] registerForRemoteNotificationTypes:(UIRemoteNotificationTypeAlert | UIRemoteNotificationTypeBadge | UIRemoteNotificationTypeSound)];

 //load persisting data : from sqlite database
[u loadPreferences:m_tUSyncPersistableConfig];


window.rootViewController = tabBarController;

[window makeKeyAndVisible];


  if (![[NSUserDefaults standardUserDefaults] boolForKey:@"HasLaunchedOnce"]) {
       //first launch//setting some values
  }else {
        //not first launch
}

    if (![[NSUserDefaults standardUserDefaults] boolForKey:@"HasLaunchedOnce"] || [u.m_tUSyncPersistableConfig.mUserName isEqualToString:@""] || !u.m_tUSyncPersistableConfig.mUserName)
{
    // This is the first launch ever
    //present login page

}
else
{
    // app already launched
  [[u commonObj] performSelectorInBackground:@selector(getAccountInfo) withObject:nil];
}

return YES;
}
Nikita P
  • 4,226
  • 5
  • 31
  • 55
  • have you check this:-http://stackoverflow.com/questions/10288133/ios-app-gets-sigkill-due-to-slow-network-connection – Nitin Gohel Jan 17 '13 at 07:07
  • that does not solve my problem. I am calling all the connection methods in background threads, none on main thread – Nikita P Jan 17 '13 at 07:09
  • http://stackoverflow.com/questions/10249377/nsurlconnection-delegate-methods-on-background-thread – Nitin Gohel Jan 17 '13 at 07:31
  • 3
    That doesn't appear to be true. The stack trace shows that you're sending a synchronous request on the main thread, using `NSURLConnection`. Are you sure you didn't miss one? – Kurt Revis Jan 17 '13 at 07:55
  • You are not returning fast enough from you application launch method, as indicated by the description at the top of the crash log. Please include that code in your question. – jrturton Jan 17 '13 at 08:16
  • @Kurt: there is one situation, where before showing a tableview, I have to get data from the server, so I am sending the request in `viewDidLoad`. But what's the alternative? I need to know atleast the number of rows for my table before completing viewDidLoad – Nikita P Jan 17 '13 at 08:16
  • 2
    @NikitaP why don't you do that work when you get the response back from the network, and in `viewDidLoad` just set up a loading indicator or something? – Carl Veazey Jan 17 '13 at 08:32

2 Answers2

1

I would strongly recommend moving away from synchronous NSURLConnection web requests. It's not recommended by Apple and is considered bad design. I suggest moving to asynchronous requests -- it might sidestep your problem, and you can handle errors with the NSURLConnection delegate method.

Rohan Agarwal
  • 2,167
  • 1
  • 24
  • 34
  • what I am doing is calling a method in a background thread, that sends the synchronous request, because i need the response then and there. If I use Asynchronous APIs, I would not know when I am getting the response, and the whole design will collapse. Isn't it? – Nikita P Jan 17 '13 at 08:13
1

Running synchronous requests in background threads is fine in general.

But the crash report shows that the synchronous request is running on the main thread. So there is at least one location where you are not running it in the background thread. And on the main thread it will block the UI and the iOS watchdog process will notice this and kill the app on startup.

So make sure, that you are never ever using synchronous requests on the main thread!

You are saying that you are doing this, but maybe you are doing it wrong. Show the code that is actually calling the connection methods. If you symbolicate the crash report it will also show these locations in the frames 8 to 10 of the thread 0 stack trace.

Kerni
  • 15,241
  • 5
  • 36
  • 57