Bug 58780 - System.Runtime.ExceptionServices.ExceptionDispatchInfo.Capture (ex).Throw () doesn't work
Summary: System.Runtime.ExceptionServices.ExceptionDispatchInfo.Capture (ex).Throw () ...
Alias: None
Product: iOS
Classification: Xamarin
Component: Mono runtime / AOT compiler ()
Version: XI 10.14 (d15-4)
Hardware: PC Mac OS
: --- normal
Target Milestone: 15.5
Assignee: Zoltan Varga
Depends on:
Reported: 2017-08-15 16:50 UTC by Rolf Bjarne Kvinge [MSFT]
Modified: 2017-09-21 12:24 UTC (History)
4 users (show)

Is this bug a regression?: Yes
Last known good build: Mono JIT compiler version

test case (for desktop) (1.61 KB, application/zip)
2017-08-15 16:50 UTC, Rolf Bjarne Kvinge [MSFT]

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description Rolf Bjarne Kvinge [MSFT] 2017-08-15 16:50:46 UTC
Created attachment 24198 [details]
test case (for desktop)

System.Runtime.ExceptionServices.ExceptionDispatchInfo.Capture (ex).Throw () doesn't work correctly when called in a reverse pinvoke.

The bug goes like this:

* System.Runtime.ExceptionServices.ExceptionDispatchInfo.Capture (ex) will capture the exception information
* .Throw () will throw the exception
* The reverse-invoke will capture the exception, and throw (not rethrow) it.
* Throwing the exception (instead of re throwing it) will clear the stack trace.
* Mono will then try to setup the stack again, and set MonoException.trace_ips to NULL (because there are no managed frames on the stack): https://github.com/mono/mono/blob/9ba3fa0ba37c3b11b7129c3092a379711fd128e4/mono/mini/mini-exceptions.c#L1519
* The native MonoException.trace_ips field maps to the managed System.Exception._stackTrace
* System.Exception.GetStackTrace has different behavior whether the _stackTrace field is null or not: https://github.com/mono/mono/blob/9ba3fa0ba37c3b11b7129c3092a379711fd128e4/mcs/class/referencesource/mscorlib/system/exception.cs#L382. If the _stackTrace field is null, then a remoting stack trace is returned, and since that's also obviously null (no remoting in the attached test case), Exception.GetStackTrace returns null.
* As a result, the StackTrace for the thrown exception is null, even if System.Runtime.ExceptionServices.ExceptionDispatchInfo.Capture was used to (attempt to) capture it.


* Set MonoException.trace_ips to an empty array instead of NULL if there are no managed frames: https://gist.github.com/rolfbjarne/915177f818e57c02fb2b40dc691740dc

This is a spin-off of bug #58352.
Comment 1 Rolf Bjarne Kvinge [MSFT] 2017-08-15 18:19:17 UTC
This is a mono regression, for the attached test case:

> Mono JIT compiler version (2017-02/9667aa6 Fri May  5 09:12:57 EDT 2017)


> Mono JIT compiler version (2017-04/161f032 Wed Jul 26 15:23:07 EDT 2017)
> Mono JIT compiler version 5.7.0 (master/b89b696e71f Tue Aug 15 19:38:06 CEST 2017)

However it seems like it's been failing a while for XI, I tested this as far back as XI 10.0 ("mtouch (cycle8-sr0-xi: ad1cd42)") using the test case from bug #58352, and it failed in all versions.
Comment 2 Chris Hardy [MSFT] 2017-09-08 20:27:39 UTC
Moving to 15.5 as this will not make 15.4
Comment 3 Zoltan Varga 2017-09-21 12:24:51 UTC
Got fixed by the fix for: