dispatch_once in ShareKit causing crash - objective-c

I was using ShareKit for a p long time, without downloading last updates from its repository.
Now i need some of its new features, so i've pulled all last commits and tried to run my app with new ShareKit without making any changes to my code (except some small changes in includes).
App compiles without errors but when i try to execute usual Facebook sharing code - it crashes without any useful error description.
old code i want to get to work
NSURL *url = [NSURL URLWithString:[NSString stringWithUTF8String:sk::game_services::get_app_store_url()]];
SHKItem *item = [SHKItem URL:url title:[NSString stringWithUTF8String:message] contentType:SHKURLContentTypeWebpage];
[SHKFacebook shareItem:item];
and according to updated ShareKit demo app and its documentation - this code should still work.
but it doesn't
it horribly crashes in currentIndicator method of SHKActivityIndicator inside macro DEFINE_SHARED_INSTANCE_USING_BLOCK that contains dispatch_once call.
debugger just says "SIGABRT" and thats all.
i don't know what to do.

Related

nsmanageobjectcontext.save stopped working in iOS7

The project I inherited was built and launched in April 2013, and it worked perfectly for ios 5.1, ios 6.0 and ios 6.1.
However i just installed the app to an iphone that has ios7.0 and it didn't work. I looked at the code and I see that the app downloads some JSON data from the web, and then when it tries to run the following 3 lines of code, "nothing happens" after the 2nd line.
NSError error = nil;
BOOL isSuccessful =[self.tempMoc save:&error]; // where tempMoc is a NSManagedObjectContext
NSLog(#"errrrrrr ----- %# --- errrrrrr", error);
When I say nothing happens, I mean that the code execution stops on the 2nd line, and no code after that line gets fired. I tried putting a breakpoint on the second line, then stepping into the function, but nothing happens...xcode doesn't show me anything new afterwards. The app in my simulator also hangs.
I tried changing the deployment target of my project from ios6 to ios7. Again, this yielded no effects.
What should I do next?
ADDITIONAL NOTES
I've been reading other stack overflow answers and some people say the a hanging [NSManagedObjectContext save] might be a threading issue. I'm not sure how to confirm if my issue is a threading issue. I know that there's only ONE place that calls the [NSManagedObjectContext save], and that's the one place where things are hanging. I tried putting a
[self.tempMoc.persistentStoreCoordinator lock];
right after instantiating self.tempMoc, but that had no effect.
I figured out the issue.
It was indeed multiple threads manipulating the NSManagedObjectContext that caused hte save function to hang.
My solution was to rewrite the code to get rid of all the extra threads. I was left with only the main thread and this fixed the issue.

10.9 CoreBluetooth RetrivePeriperals

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]];
}
}

Getting null back from XML, but only on wi-fi only devices

I have an app that incorporates weather...data that I receive from Google's weather API. I'm busting my brain trying to figure out a problem that I'm having and I've been unsuccessful so I figured it was time to ask around on here.
Here is my code:
query = [[NSString stringWithFormat:#"%#",query] stringByAddingPercentEscapesUsingEncoding:NSUTF8StringEncoding];
NSLog(#"query: %#",query);
// SET GOOGLE WEATHER XML LOCATION
CXMLDocument *parse = [[CXMLDocument alloc]initWithContentsOfURL:[NSURL URLWithString:[NSString stringWithFormat:#"http://www.google.com/ig/api?weather=%#", query]]options:0 error:nil];
NSLog(#"URL: %#", parse);
The query variable holds my reverse geocoder location (e.g. Chicago,IL) for which I append it to the Google URL to get the XML back.
As you can see I'm logging out both the query and the parse variables. I can see that I'm getting a legit query location for my current location when the code is executed, but by the time I log the parse variable I get nothing. The parse logging shows null...nothing was returned from Google. I can see that the URL is correct and I can even go to my browser and get the data I need by using the same logged link.
Interestingly enough...it works perfectly in the simulator and it also works just fine on my iPhone running 5.1.1. I do have iOS6b4 installed on my iPad which is giving the issue, but since I'm not using any new code that was introduced in iOS6 it shouldn't cause any issues here.
Any ideas as to why the XML parsing refuses to work on a wi-fi only iPad?
BTW, before anyone tells me to start using NSXMLParser instead of TouchXML...I do have a test version that runs NSXMLParser instead and I'm getting the same issue there as well. I'm at a loss.
I finally figured this out...it actually had to do with the locationManager.
I had the following code:
if ([locationManager respondsToSelector:#selector(startMonitoringSignificantLocationChanges)]) {
[locationManager startMonitoringSignificantLocationChanges]; }
else {
[locationManager startUpdatingLocation]; }
Getting rid of the if/else statement and just going with the following resolved it:
[locationManager startUpdatingLocation];

App crash - "DiskImageCache: Could not resolve the absolute path of the old directory."

I am working on an app, where I display the data entered by user in a PDF file. PDF File is also created dynamically.
All this is fine.
I have implemented QuickLook framework to display the pdf file. When I call the QL framework, PDF file id displayed quite fine but when come back to the calling screen, my app crashes without any crash log or memory warnings.
I am calling QL with below code:
[[self navigationController] presentModalViewController:qlPreviewer animated:YES];
logs created are
DiskImageCache: Could not resolve the absolute path of the old directory.
[Switching to process 3070 thread 0x17603]
[Switching to process 3070 thread 0x15503]
This is quite interesting.....
When I run the same program in Instruments to check for leaks and Memory Management, i can only find leaks when PDF document is scrolled and all the pages are viewed.
However, interestingly there is no app crash that I can see.
Also, I did try with ZombieEnabled = YES and without it but no app crash with Instruments.
I am quite clueless on how to interpret this and have been trying different things to solve this. Also, I have tried UIWebView but the result is the same.
I was again trying something to check out the issue and found something interesting.
When i execute the code directly from X-Code - i get the crash in as explained above.
In other instance, if I execute the app by clicking on the app in the sim... no crash
I am yet to check this on device. Can someone confirm the crash on the device?
Also, Google does not have answer to this question.
Thanks in advance for your answers.
Can anyone shed some light on this?
I'm having the exact same issue.
As a workaround, you can disable or remove your 'All Exceptions' breakpoint. This might make debugging a little more difficult, but it's not as bad as having to relaunch the application all the time.
This is the breakpoint causing the issue. I had set it so long ago that I'd forgotten it was there
Deleting application from device helped me to solve this problem.
Maybe also at first you should try "Product > Clean" to ensure that all resources will be copied to your device.
I was able to fix mine with this code:
FirstViewController.h
NSURLRequest* reqObj;
#property(nonatomic, retain) NSURLRequest* reqObj;
FirstViewController.m
reqObj = [NSURLRequest requestWithUrl:url cachePolicy:NSURLRequestReloadIgnoringCacheData timeoutInterval:60.0];
NSURLConnection* conn = [[NSURLConnection alloc] initWithRequest:reqObj delegate:self];
then instead of loading it on my view after this line i waited for the connectionDidFinishLoading then load it to my view
Interesting: This has just started with my app too. No errors when checking for leaks but running the app in the sim actually is causing a Breakpoint, not a crash. I can hit the continue and the app keeps running, no problem.
My issue also is relating to a PDF, but I'm just using a web view to display a PDF from the app bundle. I've checked everything in the dealloc, it's all good, this may be a iOS 5.1 bug. I will update as I learn more.
#JimP, It isn't an iOS 5.1 bug. It has just started happening to my app as well, on iOS5.0. It seems to only affect pdfs of more than one page length, and seems to trigger most commonly on scrolling past the end of the document (although sometimes earlier also). It also seems to happen more often on a second load.
This could happen when you delete the object reference in code but having its reference in xib. Delete the outlet that you no longer need.
Just ran into this problem of loading a pdf file in an App I am converting to iOS 8. This App has been running fine since the first iPhone. I just removed the All Exceptions breakpoint to work around it.
I don't know if it's the same problem but I had an issue where switching from a PDF view to another more than three times via the tab bar controller caused a crash.
Turned out that embedding the views I was switching to within Navigation controllers put a stop to the crashing.

Application got stuck on downloading

I am working on an iPhone app, which downloads Focus list of items on each app start (6 items with images).
I'm using 1 NSMutableURLRequest for downloading 6 items textual information in a loop, then in the same method block with different for loop I'm using :
NSURL * imageURL = [NSURL URLWithString: strUrl];
NSData * imageData = [NSData dataWithContentsOfURL:imageURL];
for getting images of all 6 items. Code is working fine, if I wait till this process completes and update my list on home view.
If I try to navigate then my app stuck till its in process of download. I called complete method on Background thread, but still it got stuck for the process completion.
How can I code for this, so user can experience all navigation without stuck and when he'll come back can get the 6 items in view ?
Thanks in advance.
You could use NSURLConnections asynchronous request to do the downloads in the background
+ (void)sendAsynchronousRequest:(NSURLRequest *)request queue:(NSOperationQueue *)queue completionHandler:(void (^)(NSURLResponse*, NSData*, NSError*))handler`
That way the download won't block your code. You can also do the completion work on background thread (as long as its not working with the UI, that code ALWAYS needs to be on the main thread).