Parse crash when calling [PFFacebookUtils initializeFacebook] - semaphore_wait_trap

Question

Since the latest Parse release (v1.6.3) my app gets stuck at launch, and the last breakpoint it hits is [PFFacebookUtils initializeFacebook]; If I hit pause and look at the debugger, the stack trace looks like this:

I'm calling [PFFacebookUtils initializeFacebook] in - (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions as advised.

From googling the semaphore_wait_trap issue, it seems to be related to clashing background threads(?) in Core Data. But I've tried commenting out all my background Parse queries and it still occurs.

I tried updating pods (this occurred before updating, incidentally). I can also run the app from a clean install, until I log in to Facebook, at which point the crash happens every time I try to launch. The PFUser appears to be returning fine when queried. I've also cleared out my entire database but it didn't make a difference.

Anyone know what might be going on?

Weight

Just filed this as a bug on facebook. developers.facebook.com/bugs/383878198474328 – Festive

Answer 1

I was seeing this same issue and found that changing the order of this initialization sequence (I am using swift) got me past it (notably commenting out the local data store also unblocks it):

This gets caught in semaphore_wait_trap:

// Parse integration initialization
Parse.enableLocalDatastore()
Parse.setApplicationId("<my app id>", clientKey: "<my client key>")
PFAnalytics.trackAppOpenedWithLaunchOptions(launchOptions)
PFFacebookUtils.initializeFacebook()

This does not:

// Parse integration initialization
Parse.enableLocalDatastore()
Parse.setApplicationId("<my app id>", clientKey: "<my client key>")
PFFacebookUtils.initializeFacebook()
PFAnalytics.trackAppOpenedWithLaunchOptions(launchOptions)

Not sure of the underlying issue but hope it helps.

Dorothi

That seemed to do the trick... not sure why, but at least it works again now. Somewhat worrying that a change in the api can break live apps though... – Weight

Hmm it's started to happen again - intermittently, after running my app a few times. Works ok if I clean build and delete app, but then starts occurring again after a few runs. Tried shuffling method calls, but doesn't seem to make a difference... If I comment out enabling the local datastore, things run, but then of course I have no access to my local datastore. Updated pods but still occurs. Could this be a backend change by Parse? – Weight

Have you updated to the facebook SDK 4.0.1 and latest Parse libs? I ended up changing the init call to PFFacebookUtils.initializeFacebookWithApplicationLaunchOptions(launchOptions) when I did that (earlier today). Also watch out that you need ParseFacebookUtilsV4 if you are using cocoapods... – Dorothi

I've tried all the above, yes. It's a funny one because it doesn't occur straight away, usually only after running a few times... – Weight

Seeing the same in Obj-C – Festive

I've posted my secondary issues here: #29696190 – Weight

Answer 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.

Festive

Great, hopefully that will do the trick! If you post your answer here, I can mark it as accepted, since the above question is slightly different: #29696190 – Weight

@Weight Sounds good. I think you're going to push me over 1000 rep. – Festive