Unhelpful Swift iOS crash reports

Question

I am developing an iOS app using Swift. The app is centered around Apple Maps. I am new to iOS development. I am using Fabric.io to beta distribute the app and to get crash reports back. However, a lot of the crash reports I am getting are not very helpful. Sometimes the crash reports only specify the method where the crash happened but don't give me any clue as to why it crashed. I am trying to understand if this is standard or if I should switch to another crash reporting service.

Here is an example of such crash reports:

Crashed: com.apple.main-thread
EXC_BREAKPOINT UNKNOWN at 0x00000001000a68f8

Thread : Crashed: com.apple.main-thread
0  <APP NAME>                     0x00000001000a68f8 <APP NAME>.MapViewController.(getMapAnnotations (<APP NAME>.MapViewController) -> (Swift.Double, long : Swift.Double) -> ()).(closure #1).(closure #1) (MapViewController.swift)
1  <APP NAME>                     0x00000001000a6570 <APP NAME>.MapViewController.(getMapAnnotations (<APP NAME>.MapViewController) -> (Swift.Double, long : Swift.Double) -> ()).(closure #1).(closure #1) (MapViewController.swift)
2  libdispatch.dylib              0x0000000192ed13ac _dispatch_call_block_and_release + 24
3  libdispatch.dylib              0x0000000192ed136c _dispatch_client_callout + 16
4  libdispatch.dylib              0x0000000192ed5980 _dispatch_main_queue_callback_4CF + 932
5  CoreFoundation                 0x00000001820f9fa4 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 12
6  CoreFoundation                 0x00000001820f804c __CFRunLoopRun + 1492
7  CoreFoundation                 0x00000001820250a4 CFRunLoopRunSpecific + 396
8  GraphicsServices               0x000000018b1bf5a4 GSEventRunModal + 168
9  UIKit                          0x0000000186956aa4 UIApplicationMain + 1488
10 <APP NAME>                     0x00000001000f1914 main (AppDelegate.swift:16)
11 libdyld.dylib                  0x0000000192efaa08 start + 4

Here is the method definition of the method where the error is happening:

func getAnnotations(lat: Double, long: Double){ // ignore the lat long arguments

    var apiWrapper = apiWrapper()

    apiWrapper.search(completionHandler: {(error: NSError?, mediaElements: [MediaElement]?) in
        if error == nil {
            dispatch_async(dispatch_get_main_queue(), {
                self.myMapView!.removeAnnotations(self.myMapView!.annotations)
                self.mediaAnnotations = []
                for m in mediaElements! {
                    var annotation = CustomAnnotation(lat: m.lat,long: m.long, mediaTuple: (media.url, media.type))
                    self.mediaAnnotations.append(annotation)
                }
                self.reorganizeAnnotations(self.mediaAnnotations)
            })
        } 

    })
}

Why don't you just post the code which is crashing your app? — Leo Dabus, Feb 28 '15 at 00:02
Forgot about that :) though my question is not so much about getting help for this specific bug it is more about why the crash report is not very helpful (meaning not reporting line number where the crash happened or reason) — Anthony Silva, Feb 28 '15 at 00:05
In my experience, the most common cause of this crash is that you have a forced cast (`foo as SomeClass`), but `foo` isn't actually that class. — Aaron Brager, Feb 28 '15 at 00:11
@AaronBrager , so if this error happened while I was running the app on an iOS simulator I would probably get a more helpful error report (which would allow me to figure out that the problem was a forced cast). Is it normal not to get that type of information for crash reports? — Anthony Silva, Feb 28 '15 at 00:18
It is normal, but Swift's not very good at it yet. (It's better in Swift 1.2, but you can't ship to the App Store with that yet.) — Aaron Brager, Feb 28 '15 at 00:32
I doesn't specify the line in the crash report and I have not been able to figure it out myself yet. — Anthony Silva, Feb 28 '15 at 01:27
Add nslogs or breakpoints to see what executes before the crash. — Lyndsey Scott, Feb 28 '15 at 01:28
Any update on this? I'm having the same problem with something like 2% of my users, and it's driving me mad that I can't replicate the error! — Paulo Cesar, May 11 '15 at 15:40

score 0 · Answer 1 · answered Feb 28 '15 at 00:15

0

This is a crash report for compiled code. What you are seeing is pretty much a stack trace. I'm not sure what languages you may be familiar with, but I'm assuming something like python, where it's an interpreted language and your trace gives you line numbers etc...

If swift behaved that way, it would also mean it would be a lot easier for people to reverse engineer your compiled code.

answered Feb 28 '15 at 00:15

Jeremy Pope

3,342
1
16
17

Alright. So I understand why I would not get line numbers for instance, but is it normal that it does not even report what caused the crash? (like saying that I tried to force unwrap an optional with nil value if that was the case) – Anthony Silva Feb 28 '15 at 00:21
In the crash report, no. At that point it's compiled code. You aren't unwrapping an optional your doing whatever that was optimized down to when it was compiled. If you want descriptive debug information, you need to run it in debug mode. – Jeremy Pope Feb 28 '15 at 00:23
And that said, from my understanding you can actually get things like line numbers that caused the crash by symbolicating the crash logs. And in fact, in some of the crash reports that I am getting back, I do see line numbers. – Anthony Silva Feb 28 '15 at 00:25

Unhelpful Swift iOS crash reports

1 Answers1