Bug 46661

Summary: Runtime exception filters truncate exception stack traces on NSLog
Product: [Mono] Runtime Reporter: Mathieu Bourgeois <mathieu.bourgeois>
Component: DebuggerAssignee: Zoltan Varga <vargaz>
Status: RESOLVED FIXED    
Severity: normal CC: kumpera, ludovic, mathieu.bourgeois, mono-bugs+monotouch, mono-bugs+mono, mono-bugs+runtime
Priority: ---    
Version: master   
Target Milestone: ---   
Hardware: Macintosh   
OS: Mac OS   
Tags: Is this bug a regression?: ---
Last known good build:
Attachments: Test program

Description Mathieu Bourgeois 2016-11-09 19:54:56 UTC
Created attachment 18397 [details]
Test program

Using exception filters (when keyword) seems to truncate stack traces. We've provided a simple test file that makes the issue happen.

Right now, when we crash, we receive the following NSLog

Unhandled Exception:
System.NullReferenceException: Object reference not set to an instance of an object
  at ExceptionFilterTestLauncher.Program.Main (System.String[] args) <0x1001f28f0 + 0x0002f> in <52c9b022658e4982827eb3a96373a545#68f64df7f7e4ba01ac517343bc0cf5f0>:0

(which is truncated at the parent function of where the exception filter is hooked)
Expected log is the following

Unhandled Exception:
System.NullReferenceException: Object reference not set to an instance of an object
  at ExceptionFilterTestLauncher.Program.Test (System.Int32 i) <0x1002768a4 + 0x0001c> in <e38a8af54cfe45a1bf3c8547e9c654bd#4d2d48dcc94e8d17080b76f72906cd6f>:0 
  at ExceptionFilterTestLauncher.Program.Test2 (System.Int32 i) <0x1002768f0 + 0x0000b> in <e38a8af54cfe45a1bf3c8547e9c654bd#4d2d48dcc94e8d17080b76f72906cd6f>:0 
  at ExceptionFilterTestLauncher.Program.Main (System.String[] args) <0x100276918 + 0x0002f> in <e38a8af54cfe45a1bf3c8547e9c654bd#4d2d48dcc94e8d17080b76f72906cd6f>:0

Some extra infos that I managed to gather and could prove useful :
- If we change the exception catching behavior to catch(ArgumentException e) {}, we get the proper stack trace log
- If we change the exception catching behavior to catch(ArgumentException e) when(!HandleException e) {}, we get the truncated stack trace
- If we change the exception catching behavior for rethrowing to catch(Exception e) {throw;}, we get the proper stack trace log
- We found the behavior initially on xamarin.ios master branch from November 7th, 2016. However, we tried it on the latest stable (XI 10.2.0.5 w/XM 3.0.0.64) and I had the same problem. I even tried back to XI 9.10.0.113 and XM 2.10.0.113 and I still had the same issue.
- All tests were done directly on mac, using XCode 8.1, using iphoneos sdk 10.1 and running on an iOS device on iOS 10.1.1
Comment 1 Zoltan Varga 2016-11-27 04:22:35 UTC
Sees to be caused by this block in mini-exceptions.c:

					/*
					Here's the thing, if this is a filter clause done by a wrapper like runtime invoke, we don't want to
					trim the stackframe since if it returns FALSE we lose information.

					FIXME Not 100% sure if it's a good idea even with user clauses.
					*/
					if (is_user_frame)
						setup_stack_trace (mono_ex, dynamic_methods, initial_trace_ips, &trace_ips);

Added by e2e9b3bdf3dbe9934893498b164321c1ba6cdb10.
Comment 2 Zoltan Varga 2016-11-27 04:23:17 UTC
[Moved to the Runtime product]
Comment 3 Mathieu Bourgeois 2017-02-06 15:55:33 UTC
I've investigated your suggestion Zoltan and that was indeed the problem. setup_stack_trace was being called for user frames even if the filtering wasn't successful. I've submitted a PR for this (https://github.com/mono/mono/pull/4328). Thanks for the suggestion!
Comment 4 Ludovic Henry 2017-10-06 23:47:33 UTC
I cannot reproduce with Mono 5.8.0.2 (2017-10/a3943e28cf8)