0

Here, i am bit new to iPad developement and to objective-c. I am facing a problem here reading device logs. when i browsed through logs, people said that i have build and archive and use that build to the device. so that next time when you connected the device to your machine, device logs will automatically symbolicate the crash logs. But this is not the case.

The steps i am following right now.

  1. put the xcode configuration device and release.
  2. Build -> Build and archive.
  3. Go to Build folder, drag and drop the binary file on Itunes icon and select replace.
  4. after the testing, re-connect the ipad, go to organizer window, select the device, click on device logs.
  5. This shows the symbols only...not any clue of where it is crashed.

eg:the crash report

Thread 0 Crashed:
0   libSystem.B.dylib               0x30d7c2d4 __kill + 8
1   libSystem.B.dylib               0x30d7c2c4 kill + 4
2   libSystem.B.dylib               0x30d7c2b6 raise + 10
3   libSystem.B.dylib               0x30d90d72 abort + 50
4   libSystem.B.dylib               0x30d7e980 __assert_rtn + 152
5   libgcc_s.1.dylib                0x307e8b4e _Unwind_SjLj_Resume + 26
6   CoreFoundation                  0x35801d50 CFRunLoopRunSpecific + 432
7   CoreFoundation                  0x35801b88 CFRunLoopRunInMode + 52
8   GraphicsServices                0x320c84a4 GSEventRunModal + 108
9   GraphicsServices                0x320c8550 GSEventRun + 56
10  UIKit                           0x341dc322 -[UIApplication _run] + 406
11  UIKit                           0x341d9e8c UIApplicationMain + 664
12  My EF                           0x00002c84 main (main.m:14)
13  My EF                           0x00002c4c start + 32

Please let me know if i am doing something wrong.

thanks suresh

BoltClock
  • 700,868
  • 160
  • 1,392
  • 1,356
sbmandav
  • 1,211
  • 3
  • 16
  • 25

3 Answers3

1

I'm seeing this too.

My best guess is that an exception was thrown and was caught in frame #5 or #6. Then something went terribly wrong when it tried to reconstruct the original stack trace and abort() was called.

If this is the case, the real stack trace was lost, and you'll probably have to reproduce the problem in a debugger to see the real stack trace.

Steve
  • 211
  • 2
  • 4
0

EDIT

It is symbolicating your code - you're doing everything correctly. you can tell because it's saying main.m:14 telling you that the stack trace is on line 14 of main.m

The reason that you can't see anything else is because it's not your code :) The apple libraries are compiled for you - you just link them into your app. It can't tell you the line that crashed because you don't have the code!

This tells you that the crash happened somewhere deep inside apple's code, which isn't good news for you. you need to make this crash happen while you're running it in XCode so you can see exactly what's going on.

Off the top of my head, have you included libgcc_s in your list of linked frameworks?

Yea, it's a tricky one.

The thing that tripped me up was that it doesn't just have to be a build of the same code, it has to be the exact same build that was installed on the app. Rebuilding isn't good enough.

To solve this I use version control (specifically, git). Every time I give out a version of the app to people to test I copy the build folder into a releases/ directory. I then tag it (e.g. release_2010_12_10_showcase) so if they come back with a crash, I can ask them when I gave them the app and checkout the correct version of the build. This means I have the symbols from the build on their app and my code in XCode is exactly the same as the code they were running so I can see where the crash happened and fix it :) Then, using the magic of git, I can merge my change into my latest code :)

NS I have not used archiving apps yet - it sounds like you're doing the right thing but I think there's some sort of magic going on that only Apple understand :) I also like having everything in my version control and I don't know enough about archives in XCode to be comfortable with it. Though that probably means that I should just learn how they work!

deanWombourne
  • 38,189
  • 13
  • 98
  • 110
  • HI dean thanks for your reply. I got it. It is symbolicating. and what it is it with libgcc_s. Could you please tell me what it does and how it helps me in any way..? thanks suresh – sbmandav Dec 21 '10 at 14:00
  • I have no idea what libgcc_s is - it seems to be being wanted by something in your app. To add it as a framework, right click on the frameworks group in your project and select 'add'->'existing framework'. You should be able to find libgcc_s.1.dylib in that list. Select it and see if the app runs without crashing? – deanWombourne Dec 21 '10 at 14:21
  • How do you end up associating the stack trace given above with the code? I've got the code tagged in git, but I'm not exactly sure how I'm supposed to get associated line numbers (especially considering that it doesn't even seem to run through anything but main.m in my app - everything else is compiled in an apple / gnu framework) – smtlaissezfaire Mar 16 '11 at 22:42
0

Steps to analyze crash report:

1.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.

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

3.atos -arch armv7 -o ''/'<.dSYM filename here>' . 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

Thanks

Naveen Shan
  • 9,192
  • 3
  • 29
  • 43