Bug 8477 - Mono fails to load valid program * Assertion at cominterop.c:331, condition `MONO_CLASS_IS_INTERFACE (ic)' not met
Summary: Mono fails to load valid program * Assertion at cominterop.c:331, condition `...
Status: RESOLVED FIXED
Alias: None
Product: Runtime
Classification: Mono
Component: Remoting (show other bugs)
Version: 5.4 (2017-06)
Hardware: PC Mac OS
: Normal normal
Target Milestone: Future Cycle (TBD)
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2012-11-17 16:25 UTC by Marek Safar
Modified: 2017-10-19 19:33 UTC (History)
5 users (show)

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


Attachments
test-859 (3.50 KB, application/x-msdownload)
2012-11-17 16:25 UTC, Marek Safar
Details
test-859-lib (2.00 KB, application/x-msdownload)
2012-11-17 16:26 UTC, Marek Safar
Details


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 GitHub or Developer Community 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:
Status:
RESOLVED FIXED

Description Marek Safar 2012-11-17 16:25:14 UTC
Created attachment 2959 [details]
test-859

mono test-859.exe

* Assertion at cominterop.c:331, condition `MONO_CLASS_IS_INTERFACE (ic)' not met

Stacktrace:

  at <unknown> <0xffffffff>
  at X.Main () <0x00023>
  at (wrapper runtime-invoke) <Module>.runtime_invoke_int (object,intptr,intptr,intptr) <0xffffffff>
Comment 1 Marek Safar 2012-11-17 16:26:05 UTC
Created attachment 2960 [details]
test-859-lib
Comment 2 Rodrigo Kumpera 2017-07-14 23:30:33 UTC
I can repro this bug with master.
Comment 3 Ludovic Henry 2017-09-11 20:49:27 UTC
It reproduces with Mono 5.4.0.135 (2017-06/6425f06)
Comment 4 Marek Safar 2017-09-13 15:11:18 UTC
The sample works (don't crash) on .NET
Comment 5 Vladimir Kargov 2017-09-20 14:10:57 UTC
test-589.exe contains code that attempts to execute an incomplete internal call. However, the branch executing that code is not taken: 
  
.class private auto ansi beforefieldinit X 
       extends [mscorlib]System.Object 
{ 
  .method private hidebysig instance void  
          Test_PropertyOptionalParameters(class ['test-859-lib']C c) cil managed 
  { 
    // Code size       46 (0x2e) 
    .maxstack  8 
    IL_0000:  nop 
    IL_0001:  ldarg.1 
// Not taken 
    IL_0002:  brtrue     IL_000c 
// Jump to safety (taken) 
    IL_0007:  br         IL_002d 
  
    IL_000c:  ldarg.1 
    IL_000d:  ldsfld     class [mscorlib]System.Reflection.Missing [mscorlib]System.Reflection.Missing::Value 
    IL_0012:  callvirt   instance object ['test-859-lib']C::get_Value(object) 
  
// (...) 
  
    IL_002d:  ret 
  } // end of method X::Test_PropertyOptionalParameters 
  
  .method private hidebysig static int32  
          Main() cil managed 
  { 
    .entrypoint 
    // Code size       23 (0x17) 
    .maxstack  2 
    .locals init (class X V_0, 
             int32 V_1) 
    IL_0000:  nop 
    IL_0001:  newobj     instance void X::.ctor() 
    IL_0006:  stloc.0 
    IL_0007:  ldloc.0 
    IL_0008:  ldnull 
    IL_0009:  callvirt   instance void X::Test_PropertyOptionalParameters(class ['test-859-lib']C) 
  
// (...) 
  
  } // end of method X::Main 
  
AFAIU this happens because Mono relies on the validity of the entire function (Test-PropertyOptionalParameters) while .NET is more "tolerant" and doesn't crash on bad code that doesn't get executed.

I believe that generating an unreachable code trap instead of failing on an assertion during compilation would be the right way to fix it.
Comment 6 Ludovic Henry 2017-09-26 19:08:17 UTC
https://github.com/mono/mono/pull/5616