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 (show other bugs)
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)

See Also:
Is this bug a regression?: ---
Last known good build:


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.

Note You need to log in before you can comment on or make changes to this bug.