i'm new of using PLCrashReport and i whant to make symbolication client side. I khnow that there is many disadvantages but i want to try it, can you help me please.
I used the last version of CrashReporter and this what i done in the appDelegate class refering to this example http://plcrashreporter.googlecode.com/svn/tags/plcrashreporter-1.1-rc1/Documentation/API/example_usage_iphone.html.
The is a topic that talk about this here
PLCrashReporter - How to symbolicate crash data in-process?
Link to the library:
https://www.plcrashreporter.org/.
(void) applicationDidFinishLaunching: (UIApplication *) application {
PLCrashReporter *crashReporter = [PLCrashReporter sharedReporter];
NSError *error;
if ([crashReporter hasPendingCrashReport])
[self handleCrashReport];
if (![crashReporter enableCrashReporterAndReturnError: &error])
NSLog(#"Warning: Could not enable crash reporter: %#", error);
You are linking to an old repository and documentation. The website of PLCrashReporter is https://www.plcrashreporter.org/ and the documentation is https://www.plcrashreporter.org/documentation/api/v1.2/
To enable client side symbolication you need to initialize it with a configuration like this:
PLCrashReporterSignalHandlerType signalHandlerType = PLCrashReporterSignalHandlerTypeBSD;
PLCrashReporterSymbolicationStrategy symbolicationStrategy = PLCrashReporterSymbolicationStrategyNone;
PLCrashReporterConfig *config = [[PLCrashReporterConfig alloc] initWithSignalHandlerType: signalHandlerType
symbolicationStrategy: symbolicationStrategy];
PLCrashReporter *crashReporter = [[PLCrashReporter alloc] initWithConfiguration: config];
This is based on the latest version 1.2 available on the download page: https://www.plcrashreporter.org/download
But you are right, you should not do this:
It is slow, caused the device to lock up when the crash happens for a few seconds
It requires your app to include symbols which increased the app size by 30-50% (on average)
You won't get line number information for your code.
You should instead symbolicate the crash reports using the dSYM, e.g. on your Mac.
Related
I joined a new company last day, they use svn to store code, they even store cocoapods repos in the svn alongside the source code.
They can build and run the code successfully without any modification and without pod install
But after I check it out, I can build it successfully , but crashed when run.
The first place crashes is :
DDFileLogger *fileLogger = [[DDFileLogger alloc] init]; // File Logger
fileLogger.rollingFrequency = 60 * 60 * 24; // 24 hour rolling
fileLogger.maximumFileSize = 0;
fileLogger.logFileManager.maximumNumberOfLogFiles = 1;
fileLogger.logFileManager.logFilesDiskQuota = 0;
[DDLog addLogger:fileLogger];
_fileLogger = fileLogger;
NSLog(#"%s %#",__func__,fileLogger.logFileManager);
NSLog(#"%s %#",__func__,[fileLogger.logFileManager logsDirectory]);
after comment these lines, other places crash. it seems like it will crash at the place where 3rd-party library uses.
Can anybody help? many thanks to you!
I attach the crash logs here:
https://www.dropbox.com/s/9iqpgph6gqbnpbt/BleLocker%20%202018-11-22%20%E4%B8%8B%E5%8D%885-07.crash?dl=0
Er, I've found the reason, I evaluated a third-party security tool yesterday that will replace original clang with its own clang.
This clang will crash the app
I'm testing the framework HockeyApps for testing apps with iOS, it seems I added successfully my app.
I added a code which is triggered after the user touches a button, the code is very simple:
- (IBAction)didClickAuthenticateOptions:(id)sender {
NSString *s = #"x";
id obj = s;
NSArray *arr = obj;
NSLog(#"the array has the following lenght:");
NSLog(#"%lu", (unsigned long)[arr count]);
}
this code will terminate with a crash on my app.
I installed and executed my app normally on my iPhone, and the crash report was sent to my site:
but when I opened the crash report, I expected to get information about the file, method, line of code that provoked the crash
when I clicked on "view raw log" I got all this:
raw log
How to find the method, line and code that provoked the crash in all that log???
thanks in advance for the support
This is because you did not yet upload the correct dSYM files to HockeyApp. They are needed to translate the cryptic memory addresses back to readable filenames, method names, and line numbers.
There some more info on how to find the correct dSYM here.
I use this code to initialize iCloud access (I've got it from an Apple tutorial)
- (void)initializeiCloudAccess {
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
NSURL *ubiq = [[NSFileManager defaultManager] URLForUbiquityContainerIdentifier:nil];
if (ubiq)
NSLog(#"iCloud is available.\n");
else
NSLog(#"iCloud is not available.\n");
});
}
But I receive NSInvalidArgumentException with reason unrecognized selector sent to instance ... when I try to get ubiq;
Can anyone explain to me what's the problem with this code?
Check that your project is configured to use the latest iOS SDK (at least 5.0 to use iCloud) and that your device or simulator has iOS 5 or greater. If you need to target previous versions of iOS as well, you need a condition before sending the message:
if (NSClassFromString(#"NSUbiquitousKeyValueStore")) {
// iCloud API available, safe to send URLForUbiquityContainerIdentifier message
...
}
- (void)viewWillAppear:(BOOL)animated
{
MKUserTrackingBarButtonItem *trackingBarButtonItem = [[MKUserTrackingBarButtonItem alloc]initWithMapView:_mapView];
NSArray *barButtonItems = [NSArray arrayWithObjects:trackingBarButtonItem, nil];
mapToolbar.items = barButtonItems;
...
}
Code works fine on iPhone, but on iPad when view is unloading I get an error:
Cannot remove an observer <MKUserTrackingBarButtonItem 0x9cc0930> for the key path
"controlSize" from <UIButton 0x991b420> because it is not registered as an observer.'
I contacted Apple DTS and their answer was:
"To the best of my knowledge there is no workaround for this in the current shipping SDK. I would check the latest iOS SDK beta though and see if this is still an issue."
I am using a UIManagedDocument in iOS 5.0, running the app on the simulator, using XCode 4.2 under OSX 10.6. The code in question looks as follows:
if (![[NSFileManager defaultManager] fileExistsAtPath:[self.photoDatabase.fileURL path]]) {
// does not exist on disk, so create it
[self.photoDatabase saveToURL:self.photoDatabase.fileURL forSaveOperation:UIDocumentSaveForCreating completionHandler:^(BOOL success) {
[self setupFetchedResultsController];
[self fetchFlickrDataIntoDocument:self.photoDatabase];
}];
} else if (self.photoDatabase.documentState == UIDocumentStateClosed) {
// exists on disk, but we need to open it
// *** the following line generates the message ***
[self.photoDatabase openWithCompletionHandler:^(BOOL success) {
//[self setupFetchedResultsController];
}];
} else if (self.photoDatabase.documentState == UIDocumentStateNormal) {
// already open and ready to use
[self setupFetchedResultsController];
}
Running the marked line creates the following message on the log:
2012-01-10 22:33:17.109 Photomania[5149:4803] NSFileCoordinator: A surprising server error was signaled. Details: Connection invalid
After the message is sent, the UIManagedDocument may or may not work—I have not found the circumstances that determine this, yet.
I am pretty sure that the code is correct, as it's actually one of the code examples in the CS193p course from Stanford. The whole example can be downloaded at their website under
http://www.stanford.edu/class/cs193p/cgi-bin/drupal/
Direct link to the code:
http://www.stanford.edu/class/cs193p/cgi-bin/drupal/system/files/sample_code/Photomania_0.zip
Additionally, the code runs fine on the device itself, without generating the "surprising" message, and running all the code that comes afterwards just fine.
I have not found anything on Google, neither on the Apple Developer pages. Restarting the simulator, or XCode, or reinstalling both of them does not change the behaviour.
Any ideas?
I can only say that I've had this happen to me several times. For me, I'm lazy after I update my dataModel and so far, each time I've gotten this error it was because I had changed my data model. Usually, all I need to do is delete my app from the simulator and re-run it and it has always turned out fine. Hope this helps someone out there.
I think I have found the answer. It looks like the automatic saving for UIManagedDocument kicks in only after a few seconds on the simulator.
So I minimized the app on the simulator, by pressing the home button, and then clicked on the icon to maximize it again. And then I terminated the app in simulator.
When I re-launched the app, the database was loaded. The error still shows up - it comes because the document is in "closed" state (that's normal - that's why CS193P asked to call openWithCompletionHandler), but my data across launches is preserved. Unfortunately I have to do the minimize/maximize routine before terminating the app, or the changes are discarded at next launch.
Can you verify that this is the behavior you are able to recreate? At least for testing purposes this should be a good enough trick to use.
Try upgrading to the latest iOS 5.1. I don't think UIManagedDocument with iCloud works reliably in 5.0. This has been my experience.
I love the Stanford iTunes class. However, I think the sample code for using UIManagedDocument is wrong. In fact, he notes in the demo that he is only doing it that way because he wants to just fetch the information right then. In the code comments, he says not to use the auto-save features because the data will not be saved if the app quits. however, UIManagedDocument will save anything that's necessary before quitting. It has all pertinent handlers for quitting/multitasking/etc to make sure the data is saved.
So, if you are using that code as your example, here's a version that should work, and does not use saveToURL (I don't have a flickr account, so I didn't actually run it - but this is how the class is designed to work). Please let me know if it does not work.
- (void)fetchFlickrDataIntoDocument:(UIManagedDocument *)document
{
NSManagedObjectContext *ctx = [[NSManagedObjectContext alloc] initWithConcurrencyType: NSPrivateQueueConcurrencyType];
ctx.parentContext = document.managedObjectContext;
[ctx performBlock:^{
NSArray *photos = [FlickrFetcher recentGeoreferencedPhotos];
for (NSDictionary *flickrInfo in photos) {
[Photo photoWithFlickrInfo:flickrInfo inManagedObjectContext:ctx];
// Push changes to document MOC
[ctx save:0]; // propagates changes to parent MOC
// and tell the document it is dirty and needs to be saved
// It will be saved when the document decides its time to save
// but it *will* be saved.
[document updateChangeCount:UIDocumentChangeDone]
}
}];
}
Still had errors when the last path component for document file url was #"Database". Adding an extension #"Database.db" seems to have fixed it, everything running fine now. Have also upgraded to Lion though.
NSURL *url = [[[NSFileManager defaultManager] URLsForDirectory:NSDocumentDirectory inDomains:NSUserDomainMask] lastObject];
url = [url URLByAppendingPathComponent:#"Database.db"];