koobas.hobune.stream
4.2 iOS Exceptions Not Printed
Prior to Unity 4.2, when a game was run on device exceptions were printed to the device console. When the game crashed due to an error in your code, the exception would be printed along with the class and method name. In debug mode it would also give you a Mono stacktrack and line numbers. This was incredibly useful at debugging issues on device, but seems to have vanished since upgrading to Unity 4.2. I've tested the same application on 4.1 and 4.2 side by side, the 4.1 application prints the exception as expected but 4.2 doesn't. Is there a resolution to this?
If exception was caught by a new crash handler, then there should be a standard iOS crash report generated. If compiled with dSYM symbols, then you should be able to see stack trace. Check in Device Logs in Xcode's Organizer.
What you can also do for unhandled managed exceptions is to disable iOS crash report generation by setting ENABLE_IOS_CRASH_REPORTING to 0 in CrashReporter.mm in trampoline code, and add this in scripting:
void Start() {
AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler(MyHandler);
}
static void MyHandler(object sender, UnhandledExceptionEventArgs args)
{
Exception e = (Exception) args.ExceptionObject;
Console.WriteLine("Exception: " + e.Message);
Console.WriteLine(e.StackTrace);
}
Yep it generates an iOS crash report, but that's next to useless compared to the information we used to get in 4.1.
With ENABLE_IOS_CRASH_REPORTING set, I get a standard error report, but that contains no exception information, with ENABLE_IOS_CRASH_REPORTING unset all I see is:
Sep 3 11:03:51 Barnaby-Smiths-iPad backboardd[51] : Application 'UI$$anonymous$$itApplication:com.kwalee.crashlogtestnew[0x4a99]' exited abnormally with exit status 1 I can't work out how to get the information we used to get in 4.1 about what and where the exception was thrown, on 4.1 I would have been told the exception type, class name, method name and if it was a development build line numbers and a stack trace.Sep 3 11:03:51 Barnaby-Smiths-iPad com.apple.launchd[1] (UI$$anonymous$$itApplication:com.kwalee.crashlogtestnew[0x4a99][3152]) : (UI$$anonymous$$itApplication:com.kwalee.crashlogtestnew[0x4a99]) Exited with code: 1
I've updated the answer and added a workaround to get more info for unhandled managed exceptions.
Thanks for your response, unfortunately that hasn't seemed to help. The Debug Information Format is set to DWARF with dSY$$anonymous$$ file by default, there are stack traces in the standard iOS crash report, but there isn't any $$anonymous$$ono information.
I've tried your code for handling the unhandled exception event, unfortunately that doesn't seem to write anything to the console. I'm not too sure on how to proceed, I presume I should be able to access the $$anonymous$$ono exception which crashed the game?
If $$anonymous$$ono has caught an error (accessing null pointer, or whatever) it will throw an exception in managed side. If it's not caught by any try clauses, then above AppDomain.UnhandledException event will be triggered. If ENABLE_IOS_CRASH_REPORTING is enabled, then Unity will simulate a crash at this point. Basically it just calls CrashedCheckBellowForHintsWhy() function in trampoline code. Generated iOS crash report will lack exception information, but it should include managed calls in the callstack. Though, the names will be mangled to AOT names. For example you should see something like:
12 libsystem_c.dylib 0x37a9d7e6 _sigtramp + 42 <-- Null access caught
13 CrashReport 0x00003c98 m_Crash_DoCrash + 36 <-- Real crash here
14 CrashReport 0x00003960 m_Crash_OnGUI + 60
Here Crash is C# class, and OnGUI and DoCrash are its methods. $$anonymous$$anaged method names generally follow this pattern:
m_<Class>_<$$anonymous$$ethod>[_<Arg type>]
So if you disable ENABLE_IOS_CRASH_REPORTING and install your own handler like inthe answer, you should be able to inspect the exception. But it could be that in your case exception isn't thrown.
P.S. It's obvious, but... make sure that Start() is called before crash happens. P.S.2. It would be awesome if you could actually make a repro case and submit a bug report with it, so we can improve debugging in this type of situations.
So it turned out I hadn't got Symlink Unity Libraries checked when I built the project from Unity, checking this means I now see $$anonymous$$yHandler get fired which is great :-) Sorry, I shouldn't have missed that.
If I re-enable ENABLE_IOS_CRASH_REPORTING, I don't see the managed call stack like you posted, should I still open a bug report and upload a repro case?
IIRC there was something in the 4.2 release notes about new crash reporting stuff on iOS. Maybe the device console is the wrong place to look now?
