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.
Related
My app is crashing when I try to set value in NSMutableDictionary.
Here is the code below which demostrate the crash, I am not able to find out any crash log also in the console.
NSArray *b =[[a objectAtIndex:1] valueForKey:#"value"];
NSMutableDictionary *b1 =[b objectAtIndex:0];
NSString *str = self.tes;
[b1 setValue:str forKey:#"value"];
Please help me regarding this.
b1 Dictionary log
{
question = "vale";
type = a;
}
setValue:forKey: is part of the NSKeyValueCoding protocol, which among other things, lets you access object properties from the likes of Interface Builder. setValue:forKey: is implemented in classes other than NSDictionary.
setObject:forKey: is NSMutableDictionary's reason to exist. Its signature happens to be quite similar to setValue:forKey:, but is more generic (e.g. any key type).
So in your case just replace all setValue:forKey with setObject:forKey and valueForKey: with objectForKey:
--
Difference between objectForKey and valueForKey?
So you said you are getting EXC_BAD_ACCESS crash. Try turning on Zombies in Xcode’s Scheme editor. See Enable and Debug Zombie objects in iOS using Xcode 5.1.1. That question explains how to use it, but you don’t need to run Instruments as mentioned there.
Then just run the app and Xcode will show you the reason of EXC_BAD_ACCESS. Don’t forget to turn Zombies off after you don’t need it.
The name Zombie comes from the fact that under this mode all deallocated objects will be marked and will be kept as special regions of memory (not live, not dead, zombies). Once your code attempts to use such deallocated object, Xcode will notice and print helpful message.
I am keeping my data in a property called practiceRecords (an NSArray of dictionaries).
I check to see if the data already exists in the documents folder.
If yes, I load the data into self.practiceRecords.
If not, I build the array of dictionaries (using literal syntax), keeping this data in the self.practiceRecords property, and then write the data out to the documents folder.
(I am NOT reloading the data after writing it out)
As far as I am able to tell, there are no problems occurring during this process.
Then I have a step where I modify my data as follows ...
-(void)incNumberOfTriesFor:(NSString *)stringOfIndex {
if (self.practiceRecords)
{
int index = [stringOfIndex intValue];
int numberOfTries = [(NSNumber *)(self.practiceRecords[index][#"tries"]) intValue] + 1;
//CRASHING on this next line.
self.practiceRecords[index][#"tries"] = #(numberOfTries);
//message to helper method
[self writePracticeRecords];
}
}
So the first time through (when the array is built and written out) I get a crash at the indicated line.
The error is:
-[__NSDictionaryI setObject:forKeyedSubscript:]: unrecognized selector sent to instance
I quit the app, check the documents folder and see the data file written out with no issues.
I re-run the app, and then get no crash and the data file still looks great.
This is repeatable.
If the data file exists, no crash.
If the data first needs to be created, then a crash.
(In all cases, I manually look inside the resulting data file and see exactly what I expect to see - no issues there)
I'm not sure where to even begin squashing this bug, and would really like to understand the details of why this is happening.
Thanks very much for any help!
Just to recap the correct comments above:
-[__NSDictionaryI setObject:forKeyedSubscript:]: unrecognized selector sent to instance
NSDictionary does not implement any of the set... methods because it is immutable. You state that you're creating with literals syntax when the data is not found on disk. The literal syntax creates immutable containers
Instead, try...
// try to initialize from disk, but if not
// we can still use literal (immutable) syntax, but in a mutable container
self.practiceRecords = [NSMutableDictionary
dictionaryWithDictionary:#{ #"key" : #"value" }];
I have a file handle set up to read the contents of stdout, and when I try to pull the data out of it using availableData it hangs, but only when the app is run manually on my device. When I run the app on my device through Xcode or on the simulator, it pulls the data out as expected and the rest of my code works perfectly. Any ideas what is happening? My code is below:
int pipefd[2];
pipe(pipefd);
dup2(pipefd[1], STDOUT_FILENO);
close(pipefd[1]);
NSFileHandle *stdoutReader = [[NSFileHandle alloc] initWithFileDescriptor:pipefd[0]];
// this method writes output to stout
int result = [self createOutput:string1:string2];
// code hangs on this next line when app is run manually on device)
NSData *stdoutData = [stdoutReader availableData];
I am wondering if on my device, the createOutput method runs more slowly and so by the time I try to get data out of stdout there isn't any yet?
Well, it looks like iOS 5.1 doesn't allow writing to stdout anymore. For anyone interested in reading more, here's an informative blog post: http://spouliot.wordpress.com/2012/03/13/ios-5-1-vs-stdout/
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"];
I've struck a problem using the latest XCode beta (4.2 Build 4C114, iOS 5.0) and autorelease that I can't solve. The code needs to conditionally set a string which will be the message in an alert:
NSString* msg = ([result rangeOfString:#"Ok"].location == NSNotFound) ?
#"Upload failed" : #"Uploaded ok";
Running Analyze highlights the line saying "Object sent -autorelease too many times (2)".
And sho'nuf, running the app (under the Simulator) causes a SIGABRT double free.
I've tried coding the line as an if/else.
I've tried creating separate strings for the two messages and just assigning the appropriate pointer to a third pointer with the ternary and if/else.
Nothing I do makes this go away!
Creating a string with #"string contents" will always be autoreleased automatically. You don't need to specifically release it yourself.
In most cases you would only need to release an object if you called "alloc" or "new" on it to begin with.