Can not reproduce a crash found by the app review. Can anyone help make sense of this crash report?

Question

Apple rejected our iphone app, showing that it crashed on iPad. We could not reproduce the crash on 3 different iPads and asked them to confirm. Apple came back saying that they produced the crash on iPhone 4 (although the log shows iPhone 3). We can not reproduce it...

They produce the crash by: Launch app. Select Let me look around first. App crashes.

The log they sent us back seems to not show any of the apps own methods called:

ncident Identifier: 8B5E90DE-99FD-4279-B634-2C777209F2B3
CrashReporter Key:   6e9ccd0fcdc29915ebe22fb7376bd343cdcc252a
Hardware Model:      iPhone3,1
Process:         Snug [297]
Path:            /var/mobile/Applications/DB3EFF00-7E5E-492A-9108-1341B6371B0D/Snug.app/Snug
Identifier:      Snug
Version:         ??? (???)
Code Type:       ARM (Native)
Parent Process:  launchd [1]

Date/Time:       2012-09-09 13:00:32.642 -0700
OS Version:      iPhone OS 5.1.1 (9B206)
Report Version:  104

Exception Type:  EXC_CRASH (SIGABRT)
Exception Codes: 0x00000000, 0x00000000
Crashed Thread:  6

Thread 0 name:  Dispatch queue: com.apple.main-thread
Thread 0:
0   libsystem_kernel.dylib          0x319e7660 __semwait_signal_nocancel + 24
1   libsystem_c.dylib               0x3410b4da nanosleep$NOCANCEL + 118
2   libsystem_c.dylib               0x340dd3a0 usleep$NOCANCEL + 44
3   libsystem_c.dylib               0x340dd2b6 abort + 118
4   Snug                            0x001f8760 uncaught_exception_handler + 12
5   CoreFoundation                  0x37830950 __handleUncaughtException + 68
6   libobjc.A.dylib                 0x3553533e _objc_terminate + 122
7   libc++abi.dylib                 0x36f683be safe_handler_caller(void (*)()) + 70
8   libc++abi.dylib                 0x36f6844a std::terminate() + 14
9   libc++abi.dylib                 0x36f6981e __cxa_rethrow + 82
10  libobjc.A.dylib                 0x355352a2 objc_exception_rethrow + 6
11  CoreFoundation                  0x37786506 CFRunLoopRunSpecific + 398
12  CoreFoundation                  0x37786366 CFRunLoopRunInMode + 98
13  GraphicsServices                0x33f45432 GSEventRunModal + 130
14  UIKit                           0x31532cce UIApplicationMain + 1074
15  Snug                            0x000f590c main (main.m:16)
16  Snug                            0x000f58c0 start + 32

Thread 1 name:  Dispatch queue: com.apple.libdispatch-manager
Thread 1:
0   libsystem_kernel.dylib          0x319d73a8 kevent + 24
1   libdispatch.dylib               0x3095cea4 _dispatch_mgr_invoke + 708
2   libdispatch.dylib               0x3095cbc2 _dispatch_mgr_thread + 30

Thread 2:
0   libsystem_kernel.dylib          0x319e7cd4 __workq_kernreturn + 8
1   libsystem_c.dylib               0x3409ff36 _pthread_wqthread + 610
2   libsystem_c.dylib               0x3409fcc8 start_wqthread + 0

Thread 3:
0   libsystem_kernel.dylib          0x319e7cd4 __workq_kernreturn + 8
1   libsystem_c.dylib               0x3409ff36 _pthread_wqthread + 610
2   libsystem_c.dylib               0x3409fcc8 start_wqthread + 0

Thread 4 name:  WebThread
Thread 4:
0   libsystem_kernel.dylib          0x319d7004 mach_msg_trap + 20
1   libsystem_kernel.dylib          0x319d71fa mach_msg + 50
2   CoreFoundation                  0x378043ec __CFRunLoopServiceMachPort + 120
3   CoreFoundation                  0x37803124 __CFRunLoopRun + 876
4   CoreFoundation                  0x3778649e CFRunLoopRunSpecific + 294
5   CoreFoundation                  0x37786366 CFRunLoopRunInMode + 98
6   WebCore                         0x3312fc9c RunWebThread(void*) + 396
7   libsystem_c.dylib               0x340a572e _pthread_start + 314
8   libsystem_c.dylib               0x340a55e8 thread_start + 0

Thread 5 name:  com.apple.NSURLConnectionLoader
Thread 5:
0   libsystem_kernel.dylib          0x319d7004 mach_msg_trap + 20
1   libsystem_kernel.dylib          0x319d71fa mach_msg + 50
2   CoreFoundation                  0x378043ec __CFRunLoopServiceMachPort + 120
3   CoreFoundation                  0x37803124 __CFRunLoopRun + 876
4   CoreFoundation                  0x3778649e CFRunLoopRunSpecific + 294
5   CoreFoundation                  0x37786366 CFRunLoopRunInMode + 98
6   Foundation                      0x38016bb2 +[NSURLConnection(Loader) _resourceLoadLoop:] + 302
7   Foundation                      0x38016a7a -[NSThread main] + 66
8   Foundation                      0x380aa58a __NSThread__main__ + 1042
9   libsystem_c.dylib               0x340a572e _pthread_start + 314
10  libsystem_c.dylib               0x340a55e8 thread_start + 0

Thread 6 Crashed:
0   libsystem_kernel.dylib          0x319e7cd4 __workq_kernreturn + 8
1   libsystem_c.dylib               0x3409ff36 _pthread_wqthread + 610
2   libsystem_c.dylib               0x3409fcc8 start_wqthread + 0

Thread 7:
0   libsystem_kernel.dylib          0x319e7cd4 __workq_kernreturn + 8
1   libsystem_c.dylib               0x3409ff36 _pthread_wqthread + 610
2   libsystem_c.dylib               0x3409fcc8 start_wqthread + 0

Thread 8:
0   libsystem_kernel.dylib          0x319e7cd4 __workq_kernreturn + 8
1   libsystem_c.dylib               0x3409ff36 _pthread_wqthread + 610
2   libsystem_c.dylib               0x3409fcc8 start_wqthread + 0

Thread 9 name:  com.apple.CFSocket.private
Thread 9:
0   libsystem_kernel.dylib          0x319e7570 __select + 20
1   CoreFoundation                  0x3780863a __CFSocketManager + 726
2   libsystem_c.dylib               0x340a572e _pthread_start + 314
3   libsystem_c.dylib               0x340a55e8 thread_start + 0

Thread 6 crashed with ARM Thread State:
    r0: 0x00000004    r1: 0x00000000      r2: 0x00000000      r3: 0x00000000
    r4: 0x0c8cc800    r5: 0x0036a08c      r6: 0x04339000      r7: 0x04338fe0
    r8: 0x3f29fd30    r9: 0x00000000     r10: 0x3f29fd50     r11: 0x00000000
    ip: 0x00000170    sp: 0x04338fc0      lr: 0x3409ff3d      pc: 0x319e7cd4
  cpsr: 0x40000010

Can anyone enlighten us with this crash report?

UPDATE:

We nagged the app review team to send us the console trace, they did. In the trace it was evident that a call is being made to a String category method that does not exists.

The fault was that the particular category implementation file was not added to our release target. So everything worked perfectly but when the app was archived an implementation file was missing.

How long does the application take to launch and crash? Looks like you have exceeded the allowed time for launch — Stavash, Sep 10 '12 at 15:06
About a second to go from the splashpage to first screen (seems standard). Then, they get to the "Let me look around first" button, clicking that apparently crashing the app. How did you come to this conclusion? — theVurt, Sep 10 '12 at 15:13
Would be kinda useful to find out what the exception is. Probably it gets printed in the console log at crash time. — Bryan, Sep 10 '12 at 15:30
Do you have any background operations running via threads you created or NSOperation or the like? It crashed on thread 6. — Bryan, Sep 10 '12 at 15:42
I would recommend adding in *crashlytics* it provides more details. On a side note, apples steps to reproduce are not always accurate. Sometimes they move the app to the background first to run api checks then bring it back to the foreground. Try doing that. Also try using the app as it wasn't intended, press the button multiple times, etc. — Bot, Sep 10 '12 at 15:46
Can you get Apple to send you the console log from their testing? — Bryan, Sep 11 '12 at 11:54
As `__workq_kernreturn` means the thread finishing state and you got `SIGABRT` signal i believe there's a callback problem, can you share the operations callback code ? — A-Live, Sep 11 '12 at 13:10
@A-Live the is the thing, the NSOperation is never being called. This loop never runs, because `_operations` has 0 objects. — theVurt, Sep 11 '12 at 13:28

score 2 · Accepted Answer · answered Sep 11 '12 at 13:01

Unfortunately this log doesn't look like it'll be too useful - it just shows the main thread handling an exception that's being re-thrown from another thread; that thread has gone off to do something else at the time of the log.

You mention your suspicion about the RestKit loop and the possibility NSOperation is throwing the exception. That's possible and worth putting a check in (and crossing your fingers that it doesn't break something else...), but it's probably time to beg the app review team to give you better steps to reproduce. See if you can pin down what you all are doing differently. I wish I had a better answer for you, but I think exploring all you can about what you're doing in the background while in this part of the app and trying to figure out the missing steps to reproduce is going to be your best bet. Good luck!

user387184 · Answer 2 · 2012-09-10T16:57:15.343

The crash happened in Thread 0 at the top most Snug line 4

   Thread 0 name:  Dispatch queue: com.apple.main-thread
Thread 0:
0   libsystem_kernel.dylib          0x319e7660 __semwait_signal_nocancel + 24
1   libsystem_c.dylib               0x3410b4da nanosleep$NOCANCEL + 118
2   libsystem_c.dylib               0x340dd3a0 usleep$NOCANCEL + 44
3   libsystem_c.dylib               0x340dd2b6 abort + 118
4   Snug                            0x001f8760 uncaught_exception_handler + 12
5   CoreFoundation                  0x37830950 __handleUncaughtException + 68
6   libobjc.A.dylib                 0x3553533e _objc_terminate + 122
7   libc++abi.dylib                 0x36f683be safe_handler_caller(void (*)()) + 70
8   libc++abi.dylib                 0x36f6844a std::terminate() + 14
9   libc++abi.dylib                 0x36f6981e __cxa_rethrow + 82
10  libobjc.A.dylib                 0x355352a2 objc_exception_rethrow + 6
11  CoreFoundation                  0x37786506 CFRunLoopRunSpecific + 398
12  CoreFoundation                  0x37786366 CFRunLoopRunInMode + 98
13  GraphicsServices                0x33f45432 GSEventRunModal + 130
14  UIKit                           0x31532cce UIApplicationMain + 1074
15  Snug                            0x000f590c main (main.m:16)
16  Snug                            0x000f58c0 start + 32

There the app caused an exception which was not caught. To symbolicate the report just drag it into xCode - you need to have the dSYM file for the reviewed version. Then xCode will show you the exact line where the problem occured. To get the dSym you need to "build and archive".

Also since the crash code is

Exception Type:  EXC_CRASH (SIGABRT)
Exception Codes: 0x00000000, 0x00000000

the reason for the crash is a memory access problem. These kind of crash reports are generated in many cases where one tries to instert a nil object into an array or dictionary. (since the crash is in the main thread and not in Thread 6 as reported)

In your case I do not see any obvious insert, however I would check the logic starting in line 16 of your main file and all the subsequent. I would assume you are accessing an object which is not existent anymore at the time of this invokation.

The crash happened on a background thread this is just where the exception is getting rethrown. — Carl Veazey, Sep 11 '12 at 09:26
this is already a symbolicated log :-/ I used xcode the symbolicate it, the non symbolicated one I got from apple has no human readable stack traces. @Carl Veazey can you see where? I can't figure it out, i see a re-throw on the main thread and thats it. — theVurt, Sep 11 '12 at 10:38
@theVurt yeah I'm stumped, this log doesn't look too useful to me :( It looks like thread 6 has gone off and started doing something else while the main thread handles the re-throw. I would just try to find out what you're doing on the background thread on launch / return from background; and perhaps see if there's anything you're doing differently in your debug / adhoc builds. — Carl Veazey, Sep 11 '12 at 12:52
@CarlVeazey did you see my update, any thoughts? thanks for your time. — theVurt, Sep 11 '12 at 12:56
@theVurt yeah interesting catch. Keep looking for things like that, and check my answer - I think it's time to try to beg as much info out of Apple as possible — Carl Veazey, Sep 11 '12 at 13:02

score 0 · Answer 3 · edited May 23 '17 at 12:22

You can analyze the crash report using the below

Steps to analyze crash report from apple:

Copy the release .app file which was pushed to the appstore, the .dSYM file that was created at the time of release and the crash report receive from APPLE into a FOLDER.

OPEN terminal application and go to the folder created above (using CD command)

atos -arch armv7 -o YOURAPP.app/YOURAPP MEMORY_LOCATION_OF_CRASH. The memory location should be the one at which the app crashed as per the report.

Ex: atos -arch armv7 -o 'app name.app'/'app name' 0x0003b508

This would show you the exact line, method name which resulted in crash.

Ex: [classname functionName:]; -510

Symbolicating IPA

if we use IPA for symbolicating - just rename the extention .ipa with .zip , extract it then we can get a Payload Folder which contain app. In this case we don't need .dSYM file.

Link for this Symbolicating iPhone App Crash Reports

I've used xcode to symbolicate the report with .dSYM stored on my machine in an archive that was used to produce the IPA I don't have IPA submitted. I was under the impression that this was symbolicated already. — theVurt, Sep 11 '12 at 10:43

Can not reproduce a crash found by the app review. Can anyone help make sense of this crash report?

3 Answers3