LLDB crash

ahhh donarb, you make me feel better by saying that.Yes, at this stage of the game I just want to get it up running on my iPad and then passing Apple's scrutiny and seeing it up on the app store. It's running on my iPad now, wish me luck on the latter 2 stages.I started for this goal of creating apps 5 years ago. Never got into programming before. Worked from books like the 'For Dummies's' series. For 3 years it was like digging a bottomless pit. Then I finally found a school that taught a crash couse on Objective C. I took it and then I went from groping in the dark to dimly seeing what I was doing. My instructor looked at my plans for this app and thought it was quite original. He told me I would have to use classes that were ment for one type of application and apply them in ways that they weren't coded for. (like using the cam in the iPad for a page in my comic book rather than a camera app). He told me that what I was trying for was 'beyond advanced'. For a small fee, he helped me with the code

This is a known crasher, the AddPrinter.app program crashes each time you add a new printer (look at your Console when you click on +). I've filed a radar a few weeks ago and Apple marked it as a dupe , so they're aware of this and will issue a fix soon.

As shown at WWDC, Apple divides errors into 3 categories:Trivial errorsInt(someString), etc.Detailed, recoverable errors File not foundNetwork failureUser cancellation, etc.Logic errorsAssertions, overflows, NSException, etc.The presenter says explicitly: Int(someString) can fail, but an optional return type is fine, and in swift ErrorHandler is about the category 2.The Optionals will help trivial errors, and logic errors should crash you app, and you must fix this.I'm ok with that! Except that lack the operator try?! Let me explain:Who said i did not need to know in more detail why Int(someString) failed?That was a developer arbitrary decision based on own experience: In most cases, you just need to know that the parser failed and deal with it. Optionals are more than enough in this case.And I always can promote an error of category 1 to category 2 or even 3.// category 1 if let a = Int(1) { }// category 2 enum DataError : ErrorType { case ParserError } extension String { func toInt() throws -> I

Hi there,After the information you gave me I checked things out a bit further.It appears to be when the Map is loaded.I am getting differing error messages. Please see below.2015-07-06 18:00:00.078 USAShoppingMalls[4481:60b] -[__NSArrayM length]: unrecognized selector sent to instance 0x200a2910(lldb)2015-07-06 18:01:57.798 USAShoppingMalls[4490:60b] -[VGLResourceImpl length]: unrecognized selector sent to instance 0x1d1a9e90(lldb)Everything loads into the array correctly but it crashes when the mapview is displayed.I corrected a code error of 2 off ;; after setting the region.span.longitudeDelta = 7.0f;;.I also get different results depending on whether I load the Mapview and then the Annotations or the Other way around.I am not fully aware of what should be loaded first or if it should be loaded in ViewDidLoad or [super viewDidLoad];Thanks Ossie

Interesting point junkpile.Maybe you are right. However, I am sure there are many apps made for an iPhone 6 that will not work on the 1st, 2nd or even 3rd generation models. Surely, to prevent users of the app store from being unhappy with an app that won't work well, Apple will allow the maker of the app to mention memory restrictions. I also recall an article that talked about the limits an app has when it comes to how much memory it can take up on the so-called hard disk in iPhones and iPads. They moved it up from 1GB to 3GB! (If my memory serves me correctly)I have an iPhone 4s. Recently, I bought a jawbone UP 24. The app often crashes or shows other glitches on my older modle iPhone. I assumed that it was the age of my iPhone. So I bet that the situation of older models not being able to handle newer apps is common.That said, I'll certainly look into the point you just made and the suggestion of the unwind segue (I remember reading about it a while ago) as well as the setViewControllers:animated

Are you compiling with optimization enabled? When optimization is enabled, the compiler does all sorts of tricks that will be confusing if you look at backtraces. Functions are inlined and instantiated, and tail calls are replaced with jumps. Something that you might see is that several crash sites are coalesced into one, which makes it impossible to know where in the code it crashes.There should really be some option to preserve correct crash reporting even when compiling with optimization, at the expense of a few more ud2 instructions, but right now we have to live with the choice between optimization and being able to understand the crashes.