http://bugs.winehq.org/show_bug.cgi?id=9056
--- Comment #14 from Anastasius Focht <focht(a)gmx.net> 2007-09-15 15:53:38 ---
Hello again,
well actually there are more bugs in mono and wine regarding the assembly
loading mechanism. Start your engines ...
used: mono 1.2.5 win32
wine-0.9.44-379-g82ef8d7
After using the AOT cache and msvcrt._wspawnvp() workaround i stumbled over
.NET gui app (windows forms) which uses pinvoke() calls to user32.dll.
The loader tries to locate the user32.dll and crashes.
--- snip ---
...
fixme:msvcrt:_wspawnvp stub
Mono-INFO: Assembly Loader loaded assembly from location: 'C:\Program
Files\Mono-1.2.5\lib\mono\gac\Mono.Posix\2.0.0.0__0738eb9f132ed756\Mono.Posix.dll'.
Mono-INFO: Config attempting to parse: 'C:\Program
Files\Mono-1.2.5\lib\mono\gac\Mono.Posix\2.0.0.0__0738eb9f132ed756\Mono.Posix.dll.config'.
Mono-INFO: Config attempting to parse: 'C:\Program
Files\Mono-1.2.5\lib\..\etc\mono\assemblies\Mono.Posix\Mono.Posix.config'.
Mono-INFO: Assembly Ref addref System.Windows.Forms 00196660 -> Mono.Posix
001922E8: 2
Mono-INFO: DllImport attempting to load: 'user32.dll'.
Mono-INFO: DllImport loading location: 'user32.dll.dll'.
Stacktrace:
at System.Windows.Forms.XplatUIWin32.GetInstance () <0xffffffff>
at System.Windows.Forms.XplatUIWin32.GetInstance () <0x00020>
at System.Windows.Forms.XplatUI..cctor () <0x000b8>
at (wrapper runtime-invoke)
System.Windows.Forms.Application.runtime_invoke_void
(object,intptr,intptr,intptr) <0xffffffff>
at System.Windows.Forms.Application.EnableVisualStyles () <0xffffffff>
at System.Windows.Forms.Application.EnableVisualStyles () <0x00008>
at crc32_gui.Program.Main () <0x00008>
at (wrapper runtime-invoke) crc32_gui.Program.runtime_invoke_void
(object,intptr,intptr,intptr) <0xffffffff>
--- snip ---
Notice the message "DllImport loading location: 'user32.dll.dll'."
Further search in mono source reveals this comes from
mono/mono/metadata/loader.c:mono_lookup_pinvoke_call() which tries to load the
module using a variety of names.
This function calls mono/mono/utils/mono-dl.c:mono_dl_build_path() to return
possible file names of the library.
Well mono_dl_build_path() assumes the library parameter is the "base name of a
library". Which is of course not the case: full name supplied instead. ".dll"
is mistakenly appended for all assemblies.
Next the module should be loaded:
mono_lookup_pinvoke_call() -> cached_module_load() -> mono_dl_open()
It fails loading dll (LL_SO_OPEN -> w32_load_module -> LoadLibrary()).
Of course: user32.dll.dll wont work.
It tries then again with ".la" suffix appended and fails again.
Now the interesting part, the error handling.
When an error is encountered, LL_SO_ERROR() is called which should return a
formatted (system) error message (pointer to buffer).
LL_SO_ERROR maps to "w32_dlerror" which is this code:
--- snip mono-1-2-5/mono/mono/utils/mono-dl.c ---
static char* w32_dlerror (void)
{
char* ret = NULL;
wchar_t* buf = NULL;
DWORD code = GetLastError ();
if (FormatMessage (FORMAT_MESSAGE_FROM_SYSTEM |
FORMAT_MESSAGE_ALLOCATE_BUFFER, NULL,
code, MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT), buf, 0, NULL))
{
ret = g_utf16_to_utf8 (buf, wcslen(buf), NULL, NULL, NULL);
LocalFree (buf);
}
return ret;
}
--- snip mono-1-2-5/mono/mono/utils/mono-dl.c ---
Can you spot the bug?
Hint: FORMAT_MESSAGE_ALLOCATE_BUFFER tells the callee to allocate memory.
Well, try to store the returned buffer pointer in nirvana and fail miserably
;-)
So actually it's both: a mono and a wine bug.
Mono should actually do FormatMessage( ...., &buf, ...) and Wine should
actually watch for supplied NULL ptrs in FormatMessageA/W() before trying to
access them (copy).
Now you might think "ok, that's it". No it isnt over yet ;-)
After i quick-fixed wine's FormatMessageA/W to handle buf == NULL case
(returning 0 length) mono crashed again.
Well mono assumes if any error occurs a system generated error message must be
returned.
The logging mechanism depends on that. If it fails somehow, like the bug in
mono code itself, which prevents FormatMessageA/W() from returning valid error
msg buffer it crashes by deref null pointer.
--- snip pseudo code ---
ret = call_some_native_func( ... &error_msg)
if( !ret)
{
mono_trace( "... %s", error_msg);
g_free (error_msg);
}
--- snip pseudo code ---
So there is currently no way to get around these issues without fixing mono
source itself.
Wine should fix the FormatMessageA/W() and msvcrt._wspawnvp() issues.
FOR THE RECORD: the code flow and issues are essentially the same on native
windows platform (except for the FormatMessage bug).
Start console (cmd.exe) there. Enable logging (set MONO_LOG_MASK=debug). Start
mono.exe with some .net app (i used simple 2.0 .net app generated by VC2005/C#)
and see it die.
For more fun, enable AOT cache (set MONO_AOT_CACHE=1). Die.
Regards
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=6183
guebby(a)gmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |guebby(a)gmail.com
--- Comment #18 from guebby(a)gmail.com 2007-09-15 14:58:15 ---
I can play with sound but without the car's engine sound, by deleting or
removing SOUND/ENGINE directory. Anyway, when the car jumps in slow motion
(also with sound) the game crashes too, even deleting the entire SOUND
directory.
With engine's sound, some cars can "stay" without crashing the game if you do
not accelerate. With the Porsche 911 Turbo S, the game crashes when revs pass
4000 rpm. With the Corvette it happens before 1000 rpm.
My Wine version is 0.9.45 on a Gentoo Linux 2.6.20 x86_64 single core.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=2891
Stuart Middleton <Stuart(a)houseofanime.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |Stuart(a)houseofanime.org
--- Comment #7 from Stuart Middleton <Stuart(a)houseofanime.org> 2007-09-15 13:40:05 ---
Some elements of this bug sound similar to the much more recent <a
href="http://bugs.winehq.org/show_bug.cgi?id=9512">9512,a>. I wonder if the two
are related?
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=9093
--- Comment #13 from Jacques Dion <d.dion_24(a)sympatico.ca> 2007-09-15 13:10:18 ---
(In reply to comment #12)
> 0.9.44 also affected.
>
> It works on 0.9.40, but now I get to see just how "experimental" the
> DirectDraw/OpenGL renderer is. It works with the GDI renderer, though.
>
0.9.45 also affected. Is there a "workaround" to fix this problem? 5 versions
of wine passed but still no improvement to fix this problem.................
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=5424
Mateusz Butowski <diablownik(a)gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |diablownik(a)gmail.com
--- Comment #3 from Mateusz Butowski <diablownik(a)gmail.com> 2007-09-15 12:55:18 ---
Confirming that bug's still present in wine 0.9.45.
Luke's workaround works for me. Thanks!
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=772
James Hawkins <truiken(a)gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |wine-bugs(a)winehq.org
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=772
James Hawkins <truiken(a)gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|wine-bugs(a)winehq.org |truiken(a)gmail.com
Status|REOPENED |NEW
--- Comment #7 from James Hawkins <truiken(a)gmail.com> 2007-09-15 11:44:33 ---
I've added DDE server functionality to progman, but our DDE implementation
needs a few fixes for this to work.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=5170
James Hawkins <truiken(a)gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|wine-bugs(a)winehq.org |truiken(a)gmail.com
--- Comment #11 from James Hawkins <truiken(a)gmail.com> 2007-09-15 11:42:27 ---
I'm working on DDE right now, so I'll add this to my list.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=7610
Andrew Charles Hurst <a.hurst(a)shef.ac.uk> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution| |FIXED
--- Comment #6 from Andrew Charles Hurst <a.hurst(a)shef.ac.uk> 2007-09-15 10:53:29 ---
Works with X in 16-bit colour mode.
Am replacing this with a more specific bug - namely that GF doesn't work with
24 bpp colour depth.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.