7

Since updating Facebook to v4.0.x and the latest Parse libraries, my app is hanging, seemingly when trying to log in the user.

My stack trace looks like this:

enter image description here

I had a very similar problem previously, answered here: Parse crash when calling [PFFacebookUtils initializeFacebook] - semaphore_wait_trap

However that solution no longer works, since it seems [PFUser currentUser] has been replaced with [PFUser(Private) _getCurrentUserWithOptions:] and [BFTask(Private) waitForResult:withMainThreadWarning:] where it gets stuck.

In my app, I've subclassed PFUser to a class called MPLUser, and overridden the user method. Not sure if this might be something to do with the issue?

+ (MPLUser *)user
{
    return (MPLUser *)[PFUser user];
}

Once this starts occurring, it becomes impossible to launch the app. However, I usually manage to launch the app a few times before the lock starts happening. It usually happens after a crash...

I'm using pod 'ParseFacebookUtilsV4' and have updates all libraries to latest versions.

UPDATE:

Here's more stack trace from another thread, that is seemingly trying to log on:

enter image description here enter image description here

I initialise Parse and Facebook in the following order. If I reverse the calls, it crashes:

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
    [self initDefaults];
    [self initialiseApplicationSpecifics];
    [self setupParseWithOptions:launchOptions];
    [self enableCrashReporting];
    [self setupIAPs]; 
//etc... 
}


- (void)initialiseApplicationSpecifics
{
    [Flurry setCrashReportingEnabled:YES];
    [self registerParseSubclasses];
    [ParseCrashReporting enable];
    [Parse enableLocalDatastore];
#ifdef MPL
    [Parse setApplicationId:@"xxxyyy"
                  clientKey:@"xxxyyy"];
    [Flurry startSession:@"xxxyyy"];
#elif MGM
    [Parse setApplicationId:@"yyyxxx"
                  clientKey:@"yyyxxx"];
    [Flurry startSession:@"yyyxxx"];
#endif
}

- (void)setupParseWithOptions:(NSDictionary *)launchOptions
{
    [PFFacebookUtils initializeFacebookWithApplicationLaunchOptions:launchOptions];
    [PFTwitterUtils initializeWithConsumerKey:@"aaaabbbb"
                               consumerSecret:@"bbbbaaaa"];
    [PFAnalytics trackAppOpenedWithLaunchOptions:launchOptions];
}
Community
  • 1
  • 1
Smikey
  • 8,106
  • 3
  • 46
  • 74
  • What's happening on other threads at the time of the hang? – Phillip Mills Apr 20 '15 at 13:33
  • I've updated the question with some more info. There seems to be a lot happening on other threads too - Facebook and Parse initialise stuff... – Smikey Apr 20 '15 at 14:27
  • Can you add a sample program to simulate the error case at our end and debug further to understand the scenario? – Gajendra Mali Apr 20 '15 at 14:32
  • I haven't worked with these libraries but it looks to me as if multiple things are competing for the main thread. Is it possible to dispatch `setupParseWithOptions:launchOptions` into the background and see if that clears the deadlock? – Phillip Mills Apr 20 '15 at 14:43
  • Hmm, will try, but the order they run in is quite imperative, since Parse needs to finish initialising before Facebook should initialise... but I'll let you know – Smikey Apr 20 '15 at 15:11
  • Ok gave it a go on a background thread and it gets stuck at exactly the same point - waiting for a user... – Smikey Apr 20 '15 at 15:39
  • This is a bit of a longshot, but once I had a very similar issue because my `PFUser` subclass had a method named `isCurrentUser`, removing that method or changing its name fixed the issue for me. Also I don't think you need to override that method. you should be able to do `MLPUser* user = [MLPUser user]` and it will cast automatically – Felix Dumit Apr 24 '15 at 17:45
  • Hmm I casted it because that's what the docs said, but I'll try removing the method. I don't overwrite isCurrentUser though, but good suggestion! – Smikey Apr 27 '15 at 10:35
  • See answer here: http://stackoverflow.com/questions/28701077/parse-crash-when-calling-pffacebookutils-initializefacebook-semaphore-wait-t – Liron Apr 28 '15 at 12:33

3 Answers3

2

Seems to be fixed with parse 1.7.2

According to v1.7.2 — April 27, 2015

New: Local Data Sharing for Extensions and WatchKit. Improved nullability annotations for ParseFacebookUtils.
Fixed: logOutInBackground with block callback not called on main thread. Fixed: Potential compilation error with using imports for PFSubclassing.h.
Fixed: Not persistent currentUser if saving automatic user via saveEventually.
Fixed: Rare deadlock scenario with using ParseFacebookUtils and currentUser.
Fixed: Rare issue with pinning multiple objects in a row to the same pin.
Fixed: Rare scenario when user could be not linked with Facebook.
Improved performance and reliability of Local Datastore. Performance improvements.
Other small bug fixes.

Liron
  • 2,012
  • 19
  • 39
1

I'm having the same problem with Parse 1.7.1 & FBSDK 4.0.1 and I reported the bug to Parse but with no luck so far. It has something to do with the local datastore.

https://developers.facebook.com/bugs/779176035499837

Please provide further info there.

0

I checked with my team working on the iOS SDK and was informed the latest SDK should resolve this. Can you try updating?

  • Eric, which version specifically is it that has the fix. We are seeing this problem too. Thanks! – Dan Reese Apr 23 '15 at 20:06
  • I should have mentioned that we are using the pods Parse (1.7.1), ParseFacebookUtilsV4 (1.7.1), Bolts (1.1.4), and ParseUI (1.1.3), and are still seeing the issue. As far as we can tell, it is triggered by calling [PFFacebookUtils initializeFacebookWithApplicationLaunchOptions:] too soon after [Parse setApplicationId:clientKey:]. – Dan Reese Apr 23 '15 at 20:15
  • I've commented out a lot of code without success. Deleting the app and reinstalling will fix it. But once you get stuck, you are in it until you do so. – Dan Reese Apr 23 '15 at 20:44
  • Yep we're using the latest SDK, same as @DanReese and the problem still occurs – Smikey Apr 27 '15 at 10:33