Bug 23819 - Assertion failure when failing to load an assembly
Summary: Assertion failure when failing to load an assembly
Alias: None
Product: Runtime
Classification: Mono
Component: General ()
Version: 3.8.0
Hardware: PC Mac OS
: --- normal
Target Milestone: ---
Assignee: Bugzilla
Depends on:
Reported: 2014-10-14 11:22 UTC by Jon Purdy
Modified: 2018-02-28 22:06 UTC (History)
4 users (show)

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 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:

Description Jon Purdy 2014-10-14 11:22:25 UTC
When compiling Mono from source and trying to run an F# executable, the compiled Mono searches for “FSharp.Core.dll” in its installation path; since the assembly is not found, an assertion fails in “mono_class_create_from_typedef”:

    g_assert (!mono_loader_get_last_error ())

Rather than crash with a SIGABRT, this should report the assembly that was not found (“mono_loader_get_last_error ()->assembly_name”) and exit gracefully with a failed status. At the moment, if the user wants to find out which assembly failed to load and why, they must run Mono under LLDB and use:

    MONO_LOG_LEVEL="debug" MONO_LOG_MASK="asm"
Comment 3 Matt Z 2015-01-06 18:20:24 UTC
I am seeing this on Linux with Mono 3.10 as well, but in my case I don't know of any assembly that's not in the same directory as the others. Loading the assembly first in Cecil works fine, but then mono tries to load it and gets this assertion.

* Assertion at class.c:5607, condition `!mono_loader_get_last_error ()' not met

Thread 2 (Thread 0x7f3ed150d700 (LWP 4716)):
#0  0x00007f3ed95a52ad in waitpid () from /lib64/libpthread.so.0
#1  0x00000000004a6204 in mono_handle_native_sigsegv ()
#2  <signal handler called>
#3  0x00007f3ed901e625 in raise () from /lib64/libc.so.6
#4  0x00007f3ed901fe05 in abort () from /lib64/libc.so.6
#5  0x0000000000632429 in monoeg_log_default_handler ()
#6  0x00000000006324b7 in monoeg_g_logv ()
#7  0x0000000000632577 in monoeg_assertion_message ()
#8  0x0000000000517040 in mono_class_create_from_typedef ()
#9  0x00000000005161f5 in mono_class_get_full ()
#10 0x000000000055dc85 in mono_metadata_parse_type_internal ()
#11 0x000000000055e222 in mono_metadata_parse_mh_full ()
#12 0x00000000004cf91a in method_commands_internal ()
#13 0x00000000004d928d in debugger_thread ()
#14 0x000000000062d5e6 in inner_start_thread ()
#15 0x00007f3ed959d9d1 in start_thread () from /lib64/libpthread.so.0
#16 0x00007f3ed90d49dd in clone () from /lib64/libc.so.6
Comment 4 Matt Z 2015-02-19 19:11:15 UTC
Still reproducible using Mono 3.12 on Linux x64
Comment 5 Ludovic Henry 2018-02-28 22:06:00 UTC
This has been fixed over time and I cannot reproduce with Mono (master/798c5efa52a). If there are still cases when you can reproduce, please provide the reproduction case. Thank you.