Bug 41945 - Bitcode exception-related tests failing
Summary: Bitcode exception-related tests failing
Status: CONFIRMED
Alias: None
Product: Runtime
Classification: Mono
Component: JIT (show other bugs)
Version: 4.5.X
Hardware: PC Mac OS
: Normal normal
Target Milestone: Future Cycle (TBD)
Assignee: Alexander Kyte
URL:
Depends on:
Blocks:
 
Reported: 2016-06-17 17:49 UTC by Alexander Kyte
Modified: 2016-10-13 12:22 UTC (History)
4 users (show)

Tags: bitcode_mobile_static
Is this bug a regression?: ---
Last known good build:

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 for Bug 41945 on GitHub or Developer Community if you have new information to add and do not yet see a matching new report.

If the latest results still closely match this report, you can use the original description:

  • Export the original title and description: GitHub Markdown or Developer Community HTML
  • Copy the title and description into the new report. Adjust them to be up-to-date if needed.
  • Add your new information.

In special cases on GitHub you might also want the comments: GitHub Markdown with public comments

Related Links:
Status:
CONFIRMED

Description Alexander Kyte 2016-06-17 17:49:02 UTC
exception18.exe fails because of stacktrace formatting issues and this is with
https://github.com/mono/mono/pull/3166 applied.

A lot of the threadpool exception tests are failing, likely due to
similar reasons. 
threadpool-exceptions2.exe 
threadpool-exceptions3.exe 
threadpool-exceptions5.exe 
threadpool-exceptions7.exe 

which is timing out.

Then there is exception3.exe which is reporting failure. It appears that this is due to a finalizer not running, so fin +=1 is never ran.

Stackframes-async.2.exe is getting a stack overflow.

generic-stack-traces2.2.exe is getting a Null Reference Exception.

Lastly, we seem to be violating type safety here:





generics-sharing-other-exc.2.exe
=============== generics-sharing-other-exc.2.exe.stdout ===============

=============== EOF ===============
=============== generics-sharing-other-exc.2.exe.stderr ===============

Unhandled Exception:
System.Runtime.CompilerServices.RuntimeWrappedException: An object that does not derive from System.Exception has been wrapped in a RuntimeWrappedException.
  at Gen`1[T].except () <0x103ff1f30 + 0x0007a> in <filename unknown>:0
  at main.Main () <0x103ff2050 + 0x000c6> in <filename unknown>:0
[ERROR] FATAL UNHANDLED EXCEPTION: Nested exception trying to figure out what went wrong

=============== EOF ===============

generic-array-exc.2.exe
=============== generic-array-exc.2.exe.stdout ===============

=============== EOF ===============
=============== generic-array-exc.2.exe.stderr ===============

Unhandled Exception:
System.Runtime.CompilerServices.RuntimeWrappedException: An object that does not derive from System.Exception has been wrapped in a RuntimeWrappedException.
  at Gen`1[T].except () <0x108fe4d90 + 0x0007a> in <filename unknown>:0
  at main.Main () <0x108fe4f00 + 0x000c6> in <filename unknown>:0
[ERROR] FATAL UNHANDLED EXCEPTION: Nested exception trying to figure out what went wrong

=============== EOF ===============
Comment 1 Alexander Kyte 2016-06-17 18:02:24 UTC
Delegate3.cs appears to be failing because the exception thrown by the delegate is allowed to reach the top-level.
Comment 2 Alexander Kyte 2016-06-17 18:03:42 UTC
Delegate2 also appears to rely on exception behavior for control flow. It is failing.
Comment 3 Alexander Kyte 2016-06-20 21:01:34 UTC
It looks like LLVM's inliner is dramatically shortening some of the expected stack traces for some of these tests. generic-stack-traces.exe is an example of a test that cannot pass while we allow LLVM to inline.
Comment 4 Ingo Krabbe 2016-10-13 12:22:25 UTC
All those tests work for me on centos6 with gcc-4.7, but the delegate2 test, that fails with an exception.

Compiling delegate2.cs with Visual Studio throws the same exception with a bit different runtime beaviour, naturally, because thread scheduling will be quite different on a windows system. But the test would fail too, on windows, so I assume, this test should just be removed, shouldn't it?