mixed mode assembly (still) not working on win32 build #10268

HinTak · 2018-08-23T22:28:45Z

Steps to Reproduce

Download one of the hybrid build from https://sourceforge.net/projects/hp-pxl-jetready/files/Microsoft%20Font%20Validator/old/win32.hybrid/
run

"c:/Program Files/Mono/bin/mono.exe" --mixed-mode bin/FontValidator.exe -file c:/Windows/Fonts/times.ttf +raster-tests -report-stdout

See result below:

Current Behavior

WARNING: The runtime version supported by this application is unavailable.
Using default runtime: v4.0.30319
c:/Windows/Fonts/times.ttf (file 1 of 1)
return type 0x1b unknown
* Assertion: should not be reached at ..\mono\metadata\marshal-ilgen.c:5997


abnormal program termination

Expected Behavior

c:/Windows/Fonts/times.ttf (file 1 of 1)
... a lot of information
Reports are ready!

On which platforms did you notice this

[ ] macOS
[ ] Linux
[*] Windows

Version Used:

"c:/Program Files/Mono/bin/mono.exe" --version
Mono JIT compiler version 5.14.0 (Visual Studio built mono)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
	TLS:           normal
	SIGSEGV:       normal
	Notification:  Thread + polling
	Architecture:  x86
	Disabled:      none
	Misc:          softdebug 
	Interpreter:   yes
	LLVM:          supported, not enabled.
	GC:            sgen (concurrent by default)

Stacktrace

return type 0x1b unknown
* Assertion: should not be reached at ..\mono\metadata\marshal-ilgen.c:5997


abnormal program termination

The text was updated successfully, but these errors were encountered:

HinTak · 2018-08-23T22:31:09Z

Also, this works correctly under wine with genuine microsoft dotnet framework v2.

I filed a similar bug for wine-mono also - I thought I did file one at the Xamarin bugzilla for the full mono binary but I could not find my old bug. This is mainly a re-test. It did not work the last time I tried, and I am just trying it again.

HinTak · 2018-08-23T22:33:45Z

The wine-mono issue I filed is madewokherd/wine-mono#29

HinTak · 2018-09-22T19:02:16Z

The 0x1b type is MONO_TYPE_FNPTR . The assertion happens in the manage wrapper code. The managed wrapper code differs from the native wrapper code in that it does not support this type and I don't know the reason.

I have another thought and think I might know why: the mixed mode assembly not only does P/Invoke but also reverse P/Invoke : it calls native code from C# code, and also passes a C# delegate to the C native code as function pointers for the C native code to call back. So it is not surprising that MONO_TYPE_FNPTR happens though it is probably rare.

HinTak · 2018-09-22T21:40:14Z

The current expected exception under mono 4.8 linux is:

System.NullReferenceException: Object reference not set to an instance of an object
at <Module>.?A0x6111e6f3.fs_InitializeKey (fs_SplineKey key) [0x0003a] in <11e9ca363e79484fb27ff0a6b9048ec8>:0
at <Module>.fs_Initialize (fs_GlyphInputType inputPtr, fs_GlyphInfoType outputPtr) [0x00007] in <11e9ca363e79484fb27ff0a6b9048ec8>:0
at Avalon.Media.Text.TrueType.RasterInterf..ctor () [0x00071] in <11e9ca363e79484fb27ff0a6b9048ec8>:0
at OTFontFile.Rasterizer.RasterInterf..ctor () [0x00006] in <df9660c417d2449684066e0c97300189>:0 
at OTFontFile.Rasterizer.RasterInterf.getInstance () [0x0000a] in <df9660c417d2449684066e0c97300189>:0
at OTFontFileVal.OTFileVal.GetRasterizer () [0x00000] in   <a7505ca124554d56b6c1dbab821f4549>:0 
at OTFontFileVal.OTFontVal.Validate () [0x00355] in <a7505ca124554d56b6c1dbab821f4549>:0

HinTak · 2018-09-23T18:13:28Z

For mono 5.14 onwards, it asserts at mono\metadata\marshal-ilgen.c:5997, which is a switch (sig->ret->type) {} block inside emit_managed_wrapper_ilgen(). The unknown type is MONO_TYPE_FNPTR. I feel like I should just stick another case near MONO_TYPE_PTR to deal with it the same way, possibly.

HinTak · 2018-09-23T20:56:08Z

I tried cross-compiling current master HEAD, which is 3f63bad14e26e5252b7aa25182e91ed1cd4433cb (or mono-3.0.12-22900-g3f63bad14e2 according to get describe --tags ...) with the following two changes:

diff -ruBb mono-3.0.12-22900-g3f63bad14e2.orig/mono/metadata/marshal-ilgen.c mono-3.0.12-22900-g3f63bad14e2/mono/metadata/marshal-ilgen.c
--- mono-3.0.12-22900-g3f63bad14e2.orig/mono/metadata/marshal-ilgen.c	2018-09-23 21:42:32.000000000 +0100
+++ mono-3.0.12-22900-g3f63bad14e2/mono/metadata/marshal-ilgen.c	2018-09-23 20:28:33.615699418 +0100
@@ -5977,6 +5977,7 @@
 		case MONO_TYPE_I:
 		case MONO_TYPE_U:
 		case MONO_TYPE_PTR:
+		case MONO_TYPE_FNPTR:
 		case MONO_TYPE_R4:
 		case MONO_TYPE_R8:
 		case MONO_TYPE_I8:
diff -ruBb mono-3.0.12-22900-g3f63bad14e2.orig/mono/metadata/metadata.c mono-3.0.12-22900-g3f63bad14e2/mono/metadata/metadata.c
--- mono-3.0.12-22900-g3f63bad14e2.orig/mono/metadata/metadata.c	2018-09-23 21:42:32.000000000 +0100
+++ mono-3.0.12-22900-g3f63bad14e2/mono/metadata/metadata.c	2018-09-23 21:17:23.228502251 +0100
@@ -2953,8 +2953,8 @@
 		type = m_class_get_byval_arg (type->data.array->eklass);
 		goto retry;
 	case MONO_TYPE_FNPTR:
-		//return signature_in_image (type->data.method, image);
-		g_assert_not_reached ();
+		type = mono_method_signature (type->data.method);
+                goto retry;
 	case MONO_TYPE_VAR:
 	case MONO_TYPE_MVAR:
 	{

With just the first one, I got a lot further until I hit the 2nd one; unfortunately the 2nd one in collect_type_images() seems to have broken p/invoke completely.

In the second case, it seems the current code in HEAD is incomplete anyway .

HinTak · 2018-09-23T21:22:19Z

Trying a different idea for the 2nd part, P/Invoke still broken. I guess the first part is probably incorrect.

--- mono-3.0.12-22900-g3f63bad14e2.orig/mono/metadata/marshal-ilgen.c	2018-09-23 21:42:32.000000000 +0100
+++ mono-3.0.12-22900-g3f63bad14e2/mono/metadata/marshal-ilgen.c	2018-09-23 20:28:33.615699418 +0100
@@ -5977,6 +5977,7 @@
 		case MONO_TYPE_I:
 		case MONO_TYPE_U:
 		case MONO_TYPE_PTR:
+		case MONO_TYPE_FNPTR:
 		case MONO_TYPE_R4:
 		case MONO_TYPE_R8:
 		case MONO_TYPE_I8:
diff -ruBb mono-3.0.12-22900-g3f63bad14e2.orig/mono/metadata/metadata.c mono-3.0.12-22900-g3f63bad14e2/mono/metadata/metadata.c
--- mono-3.0.12-22900-g3f63bad14e2.orig/mono/metadata/metadata.c	2018-09-23 21:42:32.000000000 +0100
+++ mono-3.0.12-22900-g3f63bad14e2/mono/metadata/metadata.c	2018-09-23 22:07:25.072537600 +0100
@@ -2953,8 +2953,8 @@
 		type = m_class_get_byval_arg (type->data.array->eklass);
 		goto retry;
 	case MONO_TYPE_FNPTR:
-		//return signature_in_image (type->data.method, image);
-		g_assert_not_reached ();
+                collect_signature_images (type->data.method, data);
+                break;
 	case MONO_TYPE_VAR:
 	case MONO_TYPE_MVAR:
 	{

HinTak · 2021-03-26T00:26:40Z

revisiting, now the error is :

The assembly mscorlib.dll was not found or could not be loaded.
It should have been installed in the `C:\Program Files\Mono\lib\mono\4.5\mscorlib.dll' directory.

H:\>"C:Program Files/Mono/bin/mono.exe" --version
Mono JIT compiler version 6.12.0 (Visual Studio built mono)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
        TLS:           __thread
        SIGSEGV:       normal
        Notification:  Thread + polling
        Architecture:  x86
        Disabled:      none
        Misc:          softdebug
        Interpreter:   yes
        Suspend:       preemptive
        GC:            sgen (concurrent by default)

This is just the official build https://download.mono-project.com/archive/6.12.0/windows-installer/mono-6.12.0.107-gtksharp-2.12.45-win32-0.msi
, running under wine staging 6.2 .

"C:\Program Files\Mono\lib\mono\4.5\mscorlib.dll" is definitely present there (I didn't do anything different from just pressing next with the installer). Maybe wine's mscoree.dll (which mscorlib.dll depends on) is not good enough? Or maybe support for mixed-mode assembly is still buggy?

kumpera added area-Runtime: JIT help wanted proposal labels Aug 24, 2018

HinTak mentioned this issue Sep 23, 2018

[marshal] Use MonoClass getters in marshal.c #7253

Merged

HinTak mentioned this issue Sep 24, 2018

better support for mixed-mode assemblies, and sort of regression madewokherd/wine-mono#29

Open

marek-safar added this to Needs triage in Proposals Review Oct 26, 2018

HinTak mentioned this issue Jan 24, 2021

New fscaler backend HinTak/Font-Validator#65

Closed

HinTak mentioned this issue Mar 26, 2021

win32 --mixed-mode can't load mscorlib.dll, but it is present #20976

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

mixed mode assembly (still) not working on win32 build #10268

mixed mode assembly (still) not working on win32 build #10268

HinTak commented Aug 23, 2018

HinTak commented Aug 23, 2018

HinTak commented Aug 23, 2018

HinTak commented Sep 22, 2018

HinTak commented Sep 22, 2018 •

edited

HinTak commented Sep 23, 2018

HinTak commented Sep 23, 2018

HinTak commented Sep 23, 2018

HinTak commented Mar 26, 2021

mixed mode assembly (still) not working on win32 build #10268

mixed mode assembly (still) not working on win32 build #10268

Comments

HinTak commented Aug 23, 2018

Steps to Reproduce

Current Behavior

Expected Behavior

On which platforms did you notice this

Stacktrace

HinTak commented Aug 23, 2018

HinTak commented Aug 23, 2018

HinTak commented Sep 22, 2018

HinTak commented Sep 22, 2018 • edited

HinTak commented Sep 23, 2018

HinTak commented Sep 23, 2018

HinTak commented Sep 23, 2018

HinTak commented Mar 26, 2021

HinTak commented Sep 22, 2018 •

edited