https://stackoverflow.com/questions/21965059
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianThat Apple isn't providing the Binary Images section in the provided crash report makes it much harder than necessary to find out what the cause is. Without the that information it is not possible to symbolicate the Last Exception Backtrace and find out more automatically.
The reason for the crash is definitely an exception inside the app, it is not because the apps main thread was blocking for too long because in that case the report would not show a Last Exception Backtrace and look very different. But using synchronous networking requests on the main thread should never be done anyway!
So how to find out more about this exception. Since the Binary Images are missing and the symbols for the system calls are already symbolicated, it is hard to find the address ranges for each system framework. But we know the load address from the app looking at the following line:
13 taptap 0x0008fde2 0x83000 + 52706
So the load address is 0x83000. Now we take the Last Exception Backtrace addresses and search for the ones that are likely belonging to the app:
0x2d9bff46 0x3819c6aa 0x2d9bfe88 0x2e347a66 0x8c47c 0x2d982114 0x2d8f6252 0x2e2dbc28 0x301b1f52
0x3019d4c4 0x3013841a 0x3013771c 0x3019cb38 0x325d5708 0x325d52f2 0x2d98a9da 0x2d98a976 0x2d98914a
0x2d8f3c22 0x2d8f3a06 0x3019bdd4 0x30197044 0x8fde2 0x386a4ab2
The ones that should belong to the app are the following:
0x8c47c 0x8fde2
0x8fde2 is the same as in the main thread and will symbolicate to something like
13 taptap 0x0008fde2 main (main.m:14)
The interesting one is 0x8c47c, which shows up 5th place from top from the exception. To get the symbol for this one, you need the apps dSYM that you submitted to Apple. You'll find it in the organizer Archives tab. Select the app and choose the entry for the app. Right mouse click the item that you used to submit to Apple and choose Show in Finder. Then another right mouse click and choose Show Package Contents. Open the dSYMs folder.
It is unknown which iPad was used and since the Binary Images section is missing we don't know it either (which would show the used architecture and UUID to verify the architecture, binary, and dSYM). So it can be either armv7 or armv7s. The newest iPad mini with retina and the iPad Air use armv7s in 32 bit mode, all other iPads also either use armv7s or armv7. So we have to try both which may return the same results.
Now open a terminal window and type:
`xcrun atos -arch armv7s -l 0x83000 DragInTheDSYMItemFromTheFinderInHere 0x8c47c`
Then use the same if it doesn't make sense and replace armv7s with armv7.
This should give you the class, method, filename and line number where the exception occured in your app. We'll still be missing the exception reason since the crash report doesn't show that and due to missing binary images we can't really symbolicate all the other addresses and use that find out more. Hopefully this will already give an idea.
Once you have that, please update your question with the details.
UPDATE: Now that the binary images where provided, I was able to symbolicate the crash report and get the Last Exception Backtrace symbols. Although without the app symbols, since I obviously don't have the dSYM.
The symbolicated report is available here: http://pastebin.com/An10dUpi
The important frames are the following
Last Exception Backtrace:
0 CoreFoundation 0x2d9bff46 __exceptionPreprocess + 126
1 libobjc.A.dylib 0x3819c6aa objc_exception_throw + 32
2 CoreFoundation 0x2d9bfe88 +[NSException raise:format:] + 98
3 Foundation 0x2e347a66 +[NSJSONSerialization JSONObjectWithData:options:error:] + 60
4 taptap 0x8c47c 0x83000 + 38012
This shows that the crash occurs because the app tries to serialize a given NSData object into json and fails to do so, because the NSData object is not a valid json string.
When symbolicating the 4th line as described above in the post, you will get the exact line in your code where this happens.
