Can't exec "/usr/bin/xcode-select": No such file or directory at ./symbolicatecrash line 63.
Use of uninitialized value $devToolsPath in scalar chomp at ./symbolicatecrash line 64.
xcrun: error: developer tools not installed; download from http://developer.apple.com
xcrun: error: developer tools not installed; download from http://developer.apple.com
Use of uninitialized value $devToolsPath in quotemeta at ./symbolicatecrash line 81.
while reading myApp_2011-08-29-170743_Users-iPhone.crash, No such file or directory : at ./symbolicatecrash line 622.
What am I doing wrong? I also tried just dragging and dropping the .crash file into organizer but that just opens up the un-symbolicated file-- no changes.
as the locations causing the crash then maybe I have found the locations.
So I used this in terminal:
atos -o myApp.app.dSYM/Contents/Resources/DWARF/myApp -arch armv6 0x000452c4
The only issue that comes to mind for me is if someone has entered in some information as a date, that does not fit format that I have created with NSDateFormatter.
However, it would be impossible for someone to have entered anything other than a date in this format because I use a UIDatePicker to enter this information. The other thing that comes to mind is if there is just too many dates for the "for" method to cycle through (there is no limit on the number of dates the user can enter). If a process takes too long will the app crash? I know this is true during launch, but I am unaware of it being a problem after.
Don't know the problem, just some thoughts/observations:
1. You are creating a new date formatter in each pass of the loop. Create it one time outside the loop.
2. I don't see where fromDate or toDate are used, which seems curious given the method name. Also don't see where anItem comes from, assume it is a property, and so you should use the accessor methods for it.
3. If the date format fails, then date will be nil. Might be an issue for whatever the itemNamed:country:date:rowNumber: method does.
4. If you are using a date picker, then why is the date stored as a string?
5. What is the point of the n variable? Just use i.
6. What is the point of creating d, either at all or as a mutable dictionary? The data is already a dictionary, so you could just reference it. And I don't see where you are modifying and of its values, so I don't see why it needs to be mutable.
7. Are these methods related in any way? I don't see either one calling the other, so I suspect these may not be the root of your problem.
4. If you are using a date picker, then why is the date stored as a string?
-because I set up the app in a dumb way initially. I saved all the date information as strings in the above format. If I hadn't done that the loop would be unnecessary. I'm considering setting up a single use method that runs when the app is launched to reformat this information, remove the loop, and set it up to save all future data as an NSDate.
Quote:
5. What is the point of the n variable? Just use i.
-There is no point, my bad. Thanks!
Quote:
6. What is the point of creating d, either at all or as a mutable dictionary? The data is already a dictionary, so you could just reference it. And I don't see where you are modifying and of its values, so I don't see why it needs to be mutable.
-again, no point. I forgot that when you alloc/init an array all the items in the array follow suit. so, yea--my bad again. Thanks!
Quote:
7. Are these methods related in any way? I don't see either one calling the other, so I suspect these may not be the root of your problem.
-they are both called by KalViewController, which is from the Kalframework, a calendar view that is very much identical to the native iphone calendar. These methods are part of collecting the dates that should be shown when the calendar is launched, and what months and days that exist on either side of that month (i.e., if it loads Sept, it also loads Aug and Oct).
The crash is reported to occur when the user presses the UIButton to load the KalViewController.
-they are both called by KalViewController, which is from the Kalframework, a calendar view that is very much identical to the native iphone calendar. These methods are part of collecting the dates that should be shown when the calendar is launched, and what months and days that exist on either side of that month (i.e., if it loads Sept, it also loads Aug and Oct).
The crash is reported to occur when the user presses the UIButton to load the KalViewController.
Well, what I mean is, since you flagged 2 lines from the crash report, generally speaking those kinds of things happen in the situation of A calls B calls C calls D, and something in D crashed, so you see A, B, C, and D in the stack trace. But that doesn't seem to be the case here, since neither of these methods calls the other, and this is all happening on the main thread. Which is why I don't think these methods, or at least not combined, are your problem.
Also, if this is happening in response to a button press that loads this view, then I'm not sure why the touches method would be activated. I'm assuming you mean that the button is in a previous view controller that is then creating this one, so why would anything in this one have been touched yet? But if it is happening in response to a button press, let's have a look at the button's action.
The UIButton call is pretty basic. The only thing that is out of the ordinary is that I intentionally set TheCalendarView to nil every time in order to reload the calendar's data:
I went through and made the changes you suggested. I also tried just adding kal.view as a subview, but for some reason this caused a crash. Haven't been able to investigate yet but will get back to you about it.
What is the difference between setting self.view = kal.view in viewDidLoad and doing it in loadView? Probably a stupid question and I'm sure there is a good answer--I would love to know why?
Well, it's a matter of the purpose of the methods. loadView. Load/create the view. viewDidLoad. The view did load. So why - in the method that is telling you that the view did load - would you replace the view?
What is the crash that happened when you made it a subview?
Aw- makes sense now that you explain it. Thank you.
The crash shows this in the console:
Code:
-[TheCalendarView tableView:numberOfRowsInSection:]: unrecognized selector sent to instance ...
***Terminating app due to uncaught exception 'NSInvalidArgumentException', reason:-[TheCalendarView tableView:numberOfRowsInSection:]: unrecognized selector sent to instance ...
Obviously not the whole console read out -- but this is what is causing the crash. I have no clue why [self.view addSubview:self.kal.view] would cause this crash and self.view = self.kal.view, doesn't.
Still stumped here. And very appreciative of your continued attention : )
There is a table somewhere that is looking at TheCalendarView for delegate methods, and not finding them.
3 possibilities:
1. This is the wrong class, specified accidentally somewhere.
2. This is the wrong class, due to a memory management issue.
3. This is the right class, but it does not implement the methods.
Wow I feel dumb. TheCalendarView did not implement numberOfSectionsInTableView or numberOfRowsInSection. When I was setting self.kal.view as self.view it worked though -- it must be calling these methods from another class when done this way... but when adding it as a subview it needs the methods in TheCalendarView. I'm not sure why this is...
Which do you think is the safest way to execute this? Should I set the view in loadView or add it as a subview?
The only difference I can see is that when I set it as a subview it is placed incorrectly so I'll have to make some adjustments to it's location.
Not sure. Seems weird, though. You have ViewControllerA, and ViewControllerB. So in ViewControllerA, why would you take the view from ViewControllerB, and make it the main view in ViewControllerA? What purpose does ViewControllerA serve, then? Why not just use ViewControllerB by itself?
But I thought that the crashing users were experiencing may be caused due to viewControllerA dealloc'ing after it pushed calendarView - thus the delegate for calendarView is dealloc'd.
That is why I created a new viewController-- viewControllerB.
The way I have it set up now is that viewControllerA pushes viewControllerB--> viewControllerB then sets up calendarView in its load methods (i.e., setting the KalDataSource and setting viewControllerB as the delegate) and finally sets calendarView's view as it's own.
I know... strange but I thought that this may be the cause, but obviously not. Users continued to report the crash after I released this change in an update.
The strangest thing about all of this is that it none of these configurations cause a crash on my personal phone or any of my test devices. Furthermore, only 8 users have reported this crash (surly there are more) but the majority of users indicate that the calendar works perfectly for them. I thought it may be an issue of the users using an old version of iOS or old iDevices but after checking in with them the users reporting crashes are using iPhone 4's with the latest version of iOS.
Right, which I thought was true. But again I was stumped (as I continue to be) and this was the only thing that I could find that may be the culprit; the delegate is released before calendarView is finished with it...
So if I go back to doing things how I had them set up initially it will definitely simplify the process but I am still perplexed as to why this crash is occurring : (
It has to be the KalDataSource or another element related to the set up of the KalViewController. But I just cannot see anything of error there.
Again, I am still unclear too; thus my vagueness in my explanation.
I have not been able to cause a crash on my personal phone or test devices, but several users report that upon tapping the UIButton (which I mentioned and posted above) that calls the -(IBAction)showCalendar method my app crashes. In my second post of this thread I show an unsymbolicated version of a crash report I obtained from a user, with the two lines related to the KalViewController symbolicated. They are the only two lines that are related to the calendar at all, the rest are related to other viewControllers totally unrelated to the calendar and to frameworks built-in to iOS.
Again, sorry for the vagueness here, but I hope this helps to clarify a bit.
I can't provide any further assistance. I'm seeing enough coding oddities that I can believe there are issues, but I can't really put my finger on it given only what has been shown so far.