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:
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:
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];
}
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.
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.
I checked with my team working on the iOS SDK and was informed the latest SDK should resolve this. Can you try updating?
Related
I have run react-native start in one terminal, and then react-native ios-run in another. My initial console.log rarely show, sometimes they do.
Lot's of times, randomly I do see:
LOG MESSAGE QUOTA EXCEEDED - SOME MESSAGES FROM THIS PROCESS HAVE BEEN DISCARDED
Are my console.log's being discarded? I tried clearing the console to see it more clearly but I can't find a way to clear console either.
On Android, I wouldn't have issue with missing console.log.
react-native logs information using syslog daemon. This daemon attempts to prevent spamming to the log (DoS attack). These limits are set on per process basis.
The simple solution is to stop/start simulator and you will be obtain new process that is not limited by the previous behaviour.
The other solution is to disable syslogd limits what will be heavilly depends on your operation system.
i found that the JavascriptCore engine won't automatically redirect the console.log to either XCode output panel or the system builtin Console.App， not to mention the self-broken log-ios command.
the only way to see console.log without remote debugging in browser is redirect(bind) it ourselves:
//Add this headers
#import <JavaScriptCore/JavaScriptCore.h>
#import <jschelpers/JavaScriptCore. h>
#import <React/RCTBridge+Private.h>
...
...
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
NSURL *jsCodeLocation;
...
...
[self.window makeKeyAndVisible];
::sleep(2); //<---!!!!!see below
JSGlobalContextRef globalContext = rootView.bridge.jsContextRef;
JSContext *context = [JSC_JSContext(globalContext) contextWithJSGlobalContextRef:globalContext];
context[#"console"][#"log"] = ^(NSString *message) {
NSLog(#"Javascript log: %#",message);
};
return YES;
}
Caution: the JSContext within reactInstance is created in another thread, I don't know how to get the loaded event(in only my project, since i don't like to modify the react-native engine), just wait sometime here for testing purpose.
For architectural reasons, I would prefer not to use the deeplink handler in the appdelegate to redirect the app upon entry.
Assuming I do not care about the initial install deeplink for now, can i do this?
- (BOOL)application:(UIApplication *)application
continueUserActivity:(NSUserActivity *)userActivity
restorationHandler:(void (^)(NSArray *))restorationHandler {
BOOL handledByBranch = [[Branch getInstance] continueUserActivity:userActivity];
if (handledByBranch) {
// REDIRECT APP TO WHERE I NEED
}
return handledByBranch;
}
Alex from Branch here: this may work in theory, but it is likely not the best approach and will miss some edge cases. While Branch uses Universal Links (the continueUserActivity method) wherever possible, there are still some situations in which your app would be launched via a URI scheme (the openURL method). You will need to handle both separately, and may run into some situations with undesirable side-effects.
You might find our instructions on how to build a custom deep link router useful.
I have just set up Flurry to track uncaught exceptions but it is not being called.
I have the most recent Flurry SDK.
In the AppDelegate.m I have imported "Flurry.h"
I have the following method to log errors:
void uncaughtExceptionHandler(NSException *exception){
[Flurry logError:#"Uncaught" message:#"Crash!" exception:exception];
}
4 .In application didFinishLaunchingWithOptions method I have set the following:
- [Flurry setCrashReportingEnabled:YES];
- NSSetUncaughtExceptionHandler(&uncaughtExceptionHandler);
- [Flurry startSession:#"flurry key"];
I have purposely written some code to make the app crash but I don't see anything getting logged in Flurry. (Flurry.com/Events/Event Logs) I have been crashing the app since yesterday.
I am using an ipad not the simulator to test.
Calling order should be this way,
[Flurry setCrashReportingEnabled:YES];
[Flurry startSession:#"flurry key"];
NSSetUncaughtExceptionHandler(&uncaughtExceptionHandler);
It may have to be in the app store for Flurry to report crashes..
Try bugsnag for error handling, it is much better. Flurry is awesome at analytics, but bugs are better reported at bugsnag.
Im developing an app on OSX that uses CoreBluetooth. I have encountered a problem on OSX Mavericks that i cant seem to get around. (All of this works perfectly on OSX 10.8).
First lets go through the flow of the application
This flow is fairly established and has been used used successfully in iOS apps and works on 10.8. So on Mavericks, the first run completes successfully. It scans, finds and connects to the device correctly. It also saves out the UUID of the device to a .plist file along with other properties.
Upon relaunch of the app, it attempts to go down the left hand column of the flow which is where the problems seem to occur.
So the first issue i noticed was that my call to self.central retrievePeripherals: never calls my delegate callback of -(void)centralManager:(CBCentralManager *)central didRetrievePeripherals:(NSArray *)peripherals
. It simply never gets the callback on Mavericks.
My next thought was "oh they have a new API for fetching peripherals on Mavericks and the old one is deprecated, lets try that". So i added in my calls to NSArray *identifiers = [self.central retrievePeripheralsWithIdentifiers:#[uuid]]; and i get caught in a sempahore wait trap. Upon closer debugging of what was going on it turned out that sometimes my CBCentralManager gets into a state of CBCentralManagerStateUnknown and never updates the state to a newer one.
The next thing i tried was to fire up Activity Monitor and kill the blued process. Finally, my delegate callback for -(void)centralManagerDidUpdateState:(CBCentralManager *)central was called with the correct CBCentralManagerStatePoweredOn so i performed retrievePeripheralsWithIdentifiers again and received an empty array.
So all of these problems seem to be linked to blued in some way. Does anyone have more insight into this process to elude as to what is going on?
My main question is. Why does this work the first time through the app but not the second? Upon quitting the app after the initial scan and connection it seems i can no longer use the system bluetooth for anything without resetting blued (which even then doesn't retrieve peripherals). Is there some sort of shutdown sequence i need to do on the CBCentralManager to keep blued from going AWOL?
Any advice would be greatly apprecciated!
While this is obviously a very old thread, I stumbled upon the same issue today and decided to post a fix for posterity.
I was trying to hack together a simple app based on the HeartRateMonitor example provided by Apple. Unfortunately, it does not work on 10.9 if autoConnect is set to TRUE, what's worse, it brings blued down on its knees.
In 10.9, a call to the (deprecated) retrievePeripherals freezes blued without a chance to restore. CBCentralManager goes into CBCentralManagerStateUnknown, Bluetooth cannot be turned on/off using OS functions etc. The only solution that I found is to killall -9 blued.
However, the synchronous retrievePeripheralsWithIdentifiers worked well for me (on 10.9.4). Here's the relevant excerpt from the modified HeartRateMonitor code:
/* Retreive already known devices */
if(autoConnect)
{
NSArray *peripherals = [manager retrievePeripheralsWithIdentifiers:[NSArray arrayWithObject:(id)aPeripheral.identifier]];
NSLog(#"Retrieved peripheral: %lu - %#", [peripherals count], peripherals);
[self stopScan];
/* If there are any known devices, automatically connect to it.*/
if([peripherals count] >=1)
{
[indicatorButton setHidden:FALSE];
[progressIndicator setHidden:FALSE];
[progressIndicator startAnimation:self];
peripheral = [peripherals objectAtIndex:0];
[peripheral retain];
[connectButton setTitle:#"Cancel"];
[manager connectPeripheral:peripheral options:[NSDictionary dictionaryWithObject:[NSNumber numberWithBool:YES] forKey:CBConnectPeripheralOptionNotifyOnDisconnectionKey]];
}
}
I'm using Localitics and ComScore libs for collecting some statistic for my app. And I have a problem with memory leaks. If any body use such libs, and know how to solve this problem. Or, maybe, it's not a problem?
in more details: after, when i commented
// [[LocalyticsSession sharedLocalyticsSession] startSession:LOCALYTICS_KEY];
// [[CSComScore census] notifyStart:COMSCORE_ACCOUNT_ID andSecret:COMSCORE_SECRET];
in didFinishLaunchingWithOptions in my appDelegate, all leaks disappear.
update
comScore
I'm using only base functions: in app there no code related to comScore except "notifyStart".
localitics
I used http://www.localytics.com/documentation/iphone-integration/ for integration this lib. My appDelegate looks exactly as said in instruction. for loging i'm using -
-(void)viewDidAppear:(BOOL)animated
{
[[LocalyticsSession sharedLocalyticsSession] tagScreen:#"Near Me."];
//here I have warning: ... may not respond to ...
}
here you have screen shot of my Performance tool:
hope it will help.
I am not sure exaclty what is wrong with your memory there. I use touchwizards.com for analysis, it has some great interaction analysis for iOS like heatmaps and more