Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BadImageFormatException when calling static virtual method in interface #82217

Closed
serialexperiment opened this issue Feb 16, 2023 · 11 comments
Closed

Comments

@serialexperiment
Copy link

serialexperiment commented Feb 16, 2023

Description

Calling static methods from an interface on another interface type implementing the first interface causes a BadImageFormatException (Method has no body) on Android. I have tried this on both an emulator and my actual Android phone, and I get the same result both ways. The exact same code works on Windows, but fails on Android. I wasn't sure if this was a runtime issue or a rosalyn issue so I just raised it here - sorry if this isn't the right place.

Reproduction Steps

Here is a simple MAUI app that reproduces the issue:
Repo link

edit by @akoeplinger See #82217 (comment) for a simpler repro

On Android:

  1. Have an interface with a static virtual member, like this:
    public interface IHaveStaticMethod { static abstract void Method(); }

  2. Have another interface that implements the first interface, like this:
    public interface IInterface : IHaveStaticMethod { static void IHaveStaticMethod.Method() { Console.WriteLine("Hello, world!"); } }

  3. Call the static method, using a method like this:
    private void CallMethod<T>() where T : IHaveStaticMethod => T.Method();

Expected behavior

The method should be called, like it is on Windows

Actual behavior

Exception: System.BadImageFormatException: Method has no body

Regression?

I don't think this is a regression, seeing as how the language feature is pretty new.

Known Workarounds

No response

Configuration

  • .NET 7
  • Only occurs on Android as far as I know (I don't have a means of testing IOS or anything else)

Other information

No response

@dotnet-issue-labeler
Copy link

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

@ghost ghost added the untriaged New issue has not been triaged by the area owner label Feb 16, 2023
@marek-safar marek-safar removed the untriaged New issue has not been triaged by the area owner label Feb 16, 2023
@marek-safar marek-safar added this to the 8.0.0 milestone Feb 16, 2023
@marek-safar
Copy link
Contributor

/cc @thaystg

@thaystg thaystg self-assigned this Mar 16, 2023
@ghost
Copy link

ghost commented Jul 25, 2023

Tagging subscribers to 'arch-android': @steveisok, @akoeplinger
See info in area-owners.md if you want to be subscribed.

Issue Details

Description

Calling static methods from an interface on another interface type implementing the first interface causes a BadImageFormatException (Method has no body) on Android. I have tried this on both an emulator and my actual Android phone, and I get the same result both ways. The exact same code works on Windows, but fails on Android. I wasn't sure if this was a runtime issue or a rosalyn issue so I just raised it here - sorry if this isn't the right place.

Reproduction Steps

Here is a simple MAUI app that reproduces the issue:
Repo link

On Android:

  1. Have an interface with a static virtual member, like this:
    public interface IHaveStaticMethod { static abstract void Method(); }

  2. Have another interface that implements the first interface, like this:
    public interface IInterface : IHaveStaticMethod { static void IHaveStaticMethod.Method() { Console.WriteLine("Hello, world!"); } }

  3. Call the static method, using a method like this:
    private void CallMethod<T>() where T : IHaveStaticMethod => T.Method();

Expected behavior

The method should be called, like it is on Windows

Actual behavior

Exception: System.BadImageFormatException: Method has no body

Regression?

I don't think this is a regression, seeing as how the language feature is pretty new.

Known Workarounds

No response

Configuration

  • .NET 7
  • Only occurs on Android as far as I know (I don't have a means of testing IOS or anything else)

Other information

No response

Author: serialexperiment
Assignees: thaystg
Labels:

os-android, area-VM-meta-mono

Milestone: 8.0.0

@SamMonoRT
Copy link
Member

cc @BrzVlad as he worked on the static virtual interface support a bit.

@thaystg
Copy link
Member

thaystg commented Aug 9, 2023

I have a fix for it here: https://github.com/dotnet/runtime/compare/main...thaystg:runtime:thays_fix_82217?expand=1
Not sure if it's good enough.

@SamMonoRT
Copy link
Member

hi @thaystg - any update of this, are we still tracking this for 8.0 ?

@thaystg
Copy link
Member

thaystg commented Oct 4, 2023

I'm not working on it. We can move it to net9. I hope @BrzVlad can take a look at my changes and give me some feedback?

@BrzVlad
Copy link
Member

BrzVlad commented Oct 4, 2023

This issue seems to consist of a constrained call where the generic type is also an interface. This looks like a duplicate of #90139. I think this is fixed on main.

@akoeplinger
Copy link
Member

akoeplinger commented Apr 16, 2024

There is still an issue in 9.0, I extracted the repro into a simpler console-based mono app:
repro.zip

  1. dotnet publish --self-contained
  2. Run bin/Release/net9.0/osx-arm64/publish/repro

Crash:

.NET 9.0.0-preview.3.24172.9
IsMono: True
Hello, world!
* Assertion at /Users/runner/work/1/s/src/mono/mono/mini/mini-generic-sharing.c:2758, condition `is_ok (error)' not met, function:mini_instantiate_gshared_info, (null) assembly:/Users/alexander/dev/test/repro/bin/Release/net9.0/osx-arm64/publish/System.Private.CoreLib.dll type:BadImageFormatException member:(null)


=================================================================
	Native Crash Reporting
=================================================================
Got a SIGABRT while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
=================================================================

=================================================================
	Native stacktrace:
=================================================================
	0x104fac858 - /Users/alexander/dev/test/repro/bin/Release/net9.0/osx-arm64/publish/libcoreclr.dylib : mono_dump_native_crash_info
	0x104f5ae74 - /Users/alexander/dev/test/repro/bin/Release/net9.0/osx-arm64/publish/libcoreclr.dylib : mono_handle_native_crash
	0x10517c138 - /Users/alexander/dev/test/repro/bin/Release/net9.0/osx-arm64/publish/libcoreclr.dylib : sigabrt_signal_handler.cold.1
	0x104fac1bc - /Users/alexander/dev/test/repro/bin/Release/net9.0/osx-arm64/publish/libcoreclr.dylib : mono_runtime_setup_stat_profiler
	0x184917584 - /usr/lib/system/libsystem_platform.dylib : _sigtramp
	0x1848e6c20 - /usr/lib/system/libsystem_pthread.dylib : pthread_kill
	0x1847f3a20 - /usr/lib/system/libsystem_c.dylib : abort
	0x10504c780 - /Users/alexander/dev/test/repro/bin/Release/net9.0/osx-arm64/publish/libcoreclr.dylib : monoeg_g_printv
	0x105059e54 - /Users/alexander/dev/test/repro/bin/Release/net9.0/osx-arm64/publish/libcoreclr.dylib : mono_log_write_logfile
	0x10504cb30 - /Users/alexander/dev/test/repro/bin/Release/net9.0/osx-arm64/publish/libcoreclr.dylib : monoeg_g_logv_nofree
	0x10504cbd4 - /Users/alexander/dev/test/repro/bin/Release/net9.0/osx-arm64/publish/libcoreclr.dylib : monoeg_assertion_message
	0x104f63524 - /Users/alexander/dev/test/repro/bin/Release/net9.0/osx-arm64/publish/libcoreclr.dylib : instantiate_info
	0x104f0a9d0 - /Users/alexander/dev/test/repro/bin/Release/net9.0/osx-arm64/publish/libcoreclr.dylib : mini_init_method_rgctx
	0x1049be120 - Unknown
	0x10486a8bc - Unknown
	0x10486abe8 - Unknown
	0x104ec4338 - /Users/alexander/dev/test/repro/bin/Release/net9.0/osx-arm64/publish/libcoreclr.dylib : mono_jit_runtime_invoke
	0x1050dd094 - /Users/alexander/dev/test/repro/bin/Release/net9.0/osx-arm64/publish/libcoreclr.dylib : mono_runtime_invoke_checked
	0x1050e4850 - /Users/alexander/dev/test/repro/bin/Release/net9.0/osx-arm64/publish/libcoreclr.dylib : mono_runtime_exec_main_checked
	0x104f19510 - /Users/alexander/dev/test/repro/bin/Release/net9.0/osx-arm64/publish/libcoreclr.dylib : mono_jit_exec
	0x104f1bfec - /Users/alexander/dev/test/repro/bin/Release/net9.0/osx-arm64/publish/libcoreclr.dylib : mono_main
	0x104f91564 - /Users/alexander/dev/test/repro/bin/Release/net9.0/osx-arm64/publish/libcoreclr.dylib : monovm_execute_assembly
	0x1047a1b90 - /Users/alexander/dev/test/repro/bin/Release/net9.0/osx-arm64/publish/libhostpolicy.dylib : _Z19run_app_for_contextRK20hostpolicy_context_tiPPKc
	0x1047a298c - /Users/alexander/dev/test/repro/bin/Release/net9.0/osx-arm64/publish/libhostpolicy.dylib : corehost_main
	0x1046d2744 - /Users/alexander/dev/test/repro/bin/Release/net9.0/osx-arm64/publish/libhostfxr.dylib : _ZN10fx_muxer_t24handle_exec_host_commandERKNSt3__112basic_stringIcNS0_11char_traitsIcEENS0_9allocatorIcEEEERK19host_startup_info_tS8_RKNS0_13unordered_mapI13known_optionsNS0_6vectorIS6_NS4_IS6_EEEE18known_options_hashNS0_8equal_toISD_EENS4_INS0_4pairIKSD
	0x1046d19c4 - /Users/alexander/dev/test/repro/bin/Release/net9.0/osx-arm64/publish/libhostfxr.dylib : _ZN10fx_muxer_t7executeENSt3__112basic_stringIcNS0_11char_traitsIcEENS0_9allocatorIcEEEEiPPKcRK19host_startup_info_tPciPi
	0x1046ce568 - /Users/alexander/dev/test/repro/bin/Release/net9.0/osx-arm64/publish/libhostfxr.dylib : hostfxr_main_startupinfo
	0x10464d510 - /Users/alexander/dev/test/repro/bin/Release/net9.0/osx-arm64/publish/repro : _Z9exe_startiPPKc
	0x10464d724 - /Users/alexander/dev/test/repro/bin/Release/net9.0/osx-arm64/publish/repro : main
	0x18455e0e0 - /usr/lib/dyld : start

=================================================================
	External Debugger Dump:
=================================================================

=================================================================
	Basic Fault Address Reporting
=================================================================
Memory around native instruction pointer (0x1848aea60):0x1848aea50  ff 0f 5f d6 c0 03 5f d6 10 29 80 d2 01 10 00 d4  .._..._..)......
0x1848aea60  03 01 00 54 7f 23 03 d5 fd 7b bf a9 fd 03 00 91  ...T.#...{......
0x1848aea70  50 e0 ff 97 bf 03 00 91 fd 7b c1 a8 ff 0f 5f d6  P........{...._.
0x1848aea80  c0 03 5f d6 70 0a 80 d2 01 10 00 d4 03 01 00 54  .._.p..........T

=================================================================
	Managed Stacktrace:
=================================================================
=================================================================
zsh: abort      bin/Release/net9.0/osx-arm64/publish/repro

@akoeplinger akoeplinger modified the milestones: 8.0.0, 9.0.0 Apr 16, 2024
@thaystg
Copy link
Member

thaystg commented Jun 28, 2024

@steveisok is someone from your team that should work on it?

@thaystg thaystg removed their assignment Jun 28, 2024
@steveisok
Copy link
Member

I think this is a duplicate of #79331. Closing.

@github-actions github-actions bot locked and limited conversation to collaborators Sep 9, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

8 participants