The line numbers in stack traces for IOS builds do not seem to
correspond to either the original sources or the .m sources generated
by the build process. Is there a way to interpret them ?
For example, in the trade below online_root.start:721 is refers to
a method in a file with only 111 lines. The correspinding .m file
has only 319 lines.
*** CN1 log ****
[null] 0:0:48,666 - Exception: java.lang.NullPointerException - null
java.lang.NullPointerException
at online_Root.start:721
at util_JWSApplication.runMain:216
at util_JWSApplication.xmain:124
at com_boardspace_BoardspaceLauncher.launchLobby:110
at com_boardspace_BoardspaceLauncher.doit:0
at com_boardspace_BoardspaceLauncher.run:51
at java_lang_Thread.runImpl:153
*** End of CN1 log ****
Try using a platform for crashing such as HockeyApp or Crashlytics, that would be easiest way to interpret the crash logs on an iOS device. If you don't go that route, you will need to understand the atos command, basically address to symbol. There are plenty of resources here about atos and how to get it working, this is the route I took and works well.
Related
（1）Some of our users said that our app sometimes does not work fluently, so how can we get the stack trace in order to know what happens at that moment?
（2）we want to get the stack trace like this:
0 CoreFoundation 0x000000018146ad8c 0x181325000 + 1334668
it should at lease includes these elements so that we can symbolicate them: the addresses of executable code, load address of the binary image, binary image name.
（3）"[NSThread callStackSymbols]" can not meet the requirements.
In a production app with the debug information stripped out, how do you convert the output of:
NSLog(#"Stack Trace: %#", [exception callStackSymbols]);
To an legible class and method name? A line number would be a blessing.
Here's the output I'm getting:
0 CoreFoundation 0x23d82f23 <redacted> + 154
1 libobjc.A.dylib 0x23519ce7 objc_exception_throw + 38
2 CoreFoundation 0x23cb92f1 <redacted> + 176
3 MyApp 0x23234815 MyApp + 440341
The final line is the bread and butter line, but when I use dwarf to find the address, nothing exists.
dwarfdump --arch armv7 MyApp.dSYM --lookup 0x00234815 | grep 'Line table'
I've read here that you need to convert the stack address to something else for dwarf or atos:
https://stackoverflow.com/a/12464678/2317728
How would I find the load address or slide address to perform the calculation? Is there not a way to calculate all this prior to sending the stacktrace to the log from within the app? If not, how would I determine and calculate these values after receiving the stack trace? Better yet, is there an easier solution I'm missing?
Note I cannot just wait for crash reports since the app is small and they will never come. I'm planning on sending the stack traces to our server to be fixed as soon as they appear.
EDITORIAL
The crash reporting tools in iOS are very rough, particularly when compared to Android. In android, the buggy lines are sent to Google analytics, you use the map to debug the line--simple (comparatively). For iOS, you are confronted with: a) waiting on user bug reports (not reasonable for a small app), b) sending stack traces to a server where there are scant tools or information on how to symbolicate the stack traces, c) relying on large quasi-commercial 3rd party libraries. This definitely makes it harder to build and scale up--hoping Apple will eventually take notice. Even more hopeful someone has spotted an easier solution I might have missed ;)
Thanks for your help!
A suggestion, you can easily get the method name, exception reason and line number using:
NSLog(#"%# Exception in %s on %d due to %#",[exception name],__PRETTY_FUNCTION__,__LINE__,[exception reason]);
I am new to XCode and Objective C. I have intentionally make a mistake to assign number to NSString*.
NSString* s = #1;
[s uppercaseString];
Though XCode gives me warning, this code will compile. But at runtime I get exception. Now I see in logs, (Sorry for image, I was not able to paste is as text properly due to formatting)
In this log, how I find exact place of error. How this log tells me which code to change.
So it looks like you are running the Release build (debug symbols stripped) and if you got that crash log in a production environment you would need to symbolicate it in order to find the line.
This Apple TN gives some details of Symbolication.
In a development environment you would simply add an exception breakpoint and run it from Xcode, as the debug symbols would not be stripped.
To understand what line causes the problem, you usually need to add exception breakpoint to your project as explained in this document;
In the bottom-left corner of the breakpoints navigator, click the
Add button.
Choose Add Exception Breakpoint.
In the Exception pop-up menu, choose the type of exception on which
you want execution to stop:
All. Stops on all exceptions.
Objective-C. Stops on Objective-C exceptions.
C++. Stops on C++ exceptions. To stop on a particular C++ exception, specify the exception name.
Choose the phase of the exception handling process at which you want program execution to stop.
Click Done.
line 5 Sam : [BIDViewController viewDidLoad] + 143 , if this is a release build , you need to resolve with symbols the memory address of the function , this is called "symbolize" the crash dump...
In the log look for your project name and you will come to know.
e.g.
line 5 Sam : [BIDViewController viewDidLoad] + 143
If you want to produce real crash without warning, try following code it will produce index out of bound exception and will crash
NSArray *array = #[#"1",#"2"];
NSLog(#"Item not accessible->%#",(NSString*)array[2]);
set Exception breaking point or enable NSZombie object
or
NSZombie
From the menu bar, choose Project > Scheme > Edit Scheme
SUMMARY
When I set an exception breakpoint, I don't get the exception message. How do I get the exception message? I already know how to get the stack trace, but that doesn't include the exception message.
DETAILS
In the past I developed iOS Apps with Xcode and when there was a problem, I'd get an error/exception. The exception would often have a message like "can't dereference null" or whatever.
Now, using Xcode 4.6.x for the past several weeks I've never gotten an exception message. I'll often get a SIGABRT. I put in the break on exception breakpoint and it will break there, but it's off in some assembly within the iOS SDK and I never get a message.
In fact, I can't remember the last time I saw anything show up in the debugger console.
Did exception info dissappear with the migration to LLVM?
It's very frustrating to have my app just crash in the SDK without knowing why. I check the last function to make sure things are set up correctly (objects allocated, etc) and they are which means I'm left with no clues.
Is it possibly a build setting held over from the past is somehow turning off exception messages?
Please reopen question. It now has an answer!
In the comments an excellent answer has been given. This should be promoted to full answer, and so I can mark the question answered and others who have this common issue can find it. In order for that to happen, the question needs to be reopened! (I'll delete this plea after that happens.)
I will update Jeff's answer here:
To have both the line causing the exception highlighted (and not UIApplicationMain() in main.m) AND to see the reason for the exception (e.g., "error: A fetch request must have an entity."), do this:
In the Breakpoint navigator:
Add (+), Add Exception Breakpoint
Select the new breakpoint, Control-Click, Edit Breakpoint
Add Action
Enter: po $arg1
The relevant part of the stack trace will be in the nagivator area.
This seems to still work in Xcode 9
Here is my addition for use with Xcode 6 and below.
Enter: po (NSException*) $eax
In Xcode 6 you must explicitly provide the object type because it is no longer inferred.
For Xcode 7-9 (based off Jeff's answer):
In the Breakpoint navigator:
Add (+), Add Exception Breakpoint
Select the new breakpoint, Control-Click, Edit Breakpoint
Add Action
Enter: po $arg1
To have both the line causing the exception highlighted (and not UIApplicationMain() in main.m) AND to see the reason for the exception (e.g., "error: A fetch request must have an entity."), do this:
In the Breakpoint navigator:
Add (+), Add Exception Breakpoint
Select the new breakpoint, Contorl-Click, Edit Breakpoint
Add Action
Enter: po $eax
The relevant part of the stack trace will be in the nagivator area.
Yes xcode is not so friendly for debugging. I like this article which helps me to understand crash logs a bit clearly))
Demystifying iOS Application Crash Logs
Also do this if you see error "message sent to deallocated instance"
'Products -> Edit Scheme -> Enable Zombie Objects'
this will enable zombie objects and when you do profile to your project choose
"zombie", cause error and you will be able to see which objects was deallocated e.g NSArray *myArray
The information I get from po $eax or po (NSException *)$eax seems to be different from what Xcode would print if no exception breakpoints are set. So I do the following,
Add an exception breakpoint
Exception occurs, breakpoint was hit -> I know the location
Temporarily disable breakpoints (second button on the left in Debug area)
Continue program execution (third button on the left in Debug area)
Details are printed -> I know the cause
Obviously not very elegant and flexible, but at least I two big questions are answered (where and why).
You can use bt or thread backtrace command to print error trace
Show the stack backtrace for the current thread.
The same stack trace you can find in crash reports
Information about current thread use currentThread
//Objective-C
po [NSThread currentThread]
//Swift
po Thread.currentThread
*Sometimes you can use fr v(or just v from XCode 10.2) when po is not working
I have a question regarding dSYM. I made an experiment with my app and added following code to it:
if (currentMenuPage_ == MenuPageAttrsVals) {
return ((ValueAndId *) [currentValues_ objectAtIndex:-1]).name;
}
as expected application crashed and crash log was generated.
However Xcode and atos can not tell me exact line where the crash is.
2 CoreFoundation 0x3192c23d -[__NSArrayI objectAtIndex:] + 165
3 MyApp 0x00053487 0x49000 + 42119
4 MyApp 0x0005102d 0x49000 + 32813
Do I have to set some special settings when building my app to generate proper dSYM?
If I call dwarfdump --uuid MyApp.app.dSYM I get a number. Does this number should appear somewhere in my crash log?
That number should appear in the first line under the Binary Images section. (It might be formatted differently, e.g. lowercase and without the - chars).
Please remember, every time you do a build, this UUID changes, and if you did not save the previous dSYM, it won't symbolicate it.
If you did not change a lot (any) code, you could replace the UUID string in the Binary Images section (keep the format in there) with the new one from the latest dSYM.
If symbolication did not work, and the UUID is correct, that folder is most likely not indexed by Spotlight, so the symbolication script can't find the dSYM.