[Bug 9056] Mono 1.2.4 fails to find mscorlib.dll on startup

[wine-bugs at winehq.org]

http://bugs.winehq.org/show_bug.cgi?id=9056


Anastasius Focht <focht at gmx.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |focht at gmx.net




--- Comment #13 from Anastasius Focht <focht at gmx.net>  2007-09-15 09:35:00 ---
Hello,

yes it's a bug in mono's assembly loader hook -> AOT code.
Judging from ximian/bugzilla comments the people there are not very interested
nor helpful "-> WONTFIX".

There are two options how to get around this...

============
1. Fix the stuff in mono source

The call chain until the bug goes as follows (pseudo/simplified):

mono_assembly_load_corlib( ASCII "v2.0.50727")
mono_assembly_open_full( ASCII "C:\Program
Files\Mono-1.2.5\lib\mono\2.0\mscorlib.dll" )
mono_assembly_load_from_full( ASCII "C:\Program
Files\Mono-1.2.5\lib\mono\2.0\mscorlib.dll" )
mono_assembly_invoke_load_hook( mscorlib)

which invokes runtime hook: load_aot_module( mscorlib)

-- quote mono/mono/mini/aot-runtime.c ---
static void
load_aot_module (MonoAssembly *assembly, gpointer user_data)
{
...
if (use_aot_cache)
                assembly->aot_module = load_aot_module_from_cache (assembly,
&aot_name);
        else {
                char *err;
                aot_name = g_strdup_printf ("%s%s", assembly->image->name,
SHARED_EXT);

                assembly->aot_module = mono_dl_open (aot_name, MONO_DL_LAZY,
&err);

                if (!assembly->aot_module) {
                        mono_trace (G_LOG_LEVEL_INFO, MONO_TRACE_AOT, "AOT
failed to load AOT module %s: %s\n", aot_name, err);
                        g_free (err);
                }
        }

...
-- quote mono/mono/mini/aot-runtime.c ---

"assembly->image->name" contains already full assembly path ("C:\Program
Files\Mono-1.2.5\lib\mono\2.0\mscorlib.dll")
So blindly appending SHARED_EXT is not a good idea in this case.

The same ".dll.dll" bug exists on native windows too.
Though the win32 mono_dl_open() version seems to be more conservative in error
handling (load hook cleanly exits).

============

Another way to get around:

2. use AOT cache to prevent buggy code path from executed (which involves wine
workaround due to missing msvcrt api)

Set environ var "MONO_AOT_CACHE"
Running the app with wine will result in a crash due to unimplemented msvcrt
api:

--- snip ---
Mono-INFO: Assembly Loader probing location: 'C:\Program
Files\Mono-1.2.5\lib\mono\2.0\mscorlib.dll'.
Mono-INFO: Image addref mscorlib 00141910 -> C:\Program
Files\Mono-1.2.5\lib\mono\2.0\mscorlib.dll 0013EDA0: 2

Mono-INFO: AOT trying to load from cache:
'c:\windows\profiles\focht\.mono\aot-cache\mscorlib-4D2007D0-9864-47B1-8A77-004C8CEB0E9D.dll'.
Mono-INFO: AOT not found.
Mono-Message: AOT precompiling assembly 'C:\Program
Files\Mono-1.2.5\lib\mono\2.0\mscorlib.dll'...
wine: Call from 0x7b840aa0 to unimplemented function msvcrt.dll._wspawnvp,
aborting
err:seh:setup_exception stack overflow 144 bytes in thread 0016 eip 7b840b3f
esp 00410f70 stack 0x411000-0x620000
--- snip ---

Quick fix is to use native msvcrt.dll (winecfg).
After that, .net apps should start successfully.

Though adding msvcrt._wspawnvp() should be a piece of cake, because the ANSI
version is already in place.

Regards.


-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.