http://bugs.winehq.org/show_bug.cgi?id=16258
Summary: .net 2.0's ngen.exe hangs while compiling a particular assembly Product: Wine Version: 1.1.9 Platform: Other URL: http://www.neoaxisgroup.com OS/Version: other Status: NEW Keywords: download, Installer Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: dank@kegel.com
http://www.neoaxisgroup.com/wiki/Tutorials/NeoAxisUbuntu says that the NeoAxis 0.57 demos run on Wine-1.1.5. However, when I tried http://www.neoaxisgroup.com/downloads/NeoAxisEngineNonCommercialSDK-0.57.exe or http://www.neoaxisgroup.com/downloads/NeoAxisEngineNonCommercialSDK-0.58.exe with wine-1.1.9, installation hung with the following output:
Compiling 1 assembly: Compiling assembly C:\Program Files\NeoAxis Engine Non-Commercial SDK 0.58\Game\Bin\Renderer.dll ... Error compiling C:\Program Files\NeoAxis Engine Non-Commercial SDK 0.58\Game\Bin\Renderer.dll: Exception from HRESULT: 0x80070004
This failure happened regardless of whether I installed lots of packages first with winetricks (as they recommend) or just dotnet20. It also happens when I try the wine-1.1.5 packages from winehq.
You can reproduce the hang with the command wine C:\windows\Microsoft.NET\Framework\v2.0.50727\ngen.exe install "C:\Program Files\NeoAxis Engine Non-Commercial SDK 0.58\Game\Bin\Renderer.dll"
There's a +relay log of that latter command at http://kegel.com/wine/log1.rz
http://bugs.winehq.org/show_bug.cgi?id=16258
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |focht@gmx.net
--- Comment #1 from Anastasius Focht focht@gmx.net 2008-12-14 17:43:25 --- Hello,
well that native image generator was a pain to debug ... Ngen's work horse actually lives in a service carrying out ngen tasks. It seems the PE image generator runs out of file descriptors while writing out native images. My first thought was: handle leak...
When dumping the file descriptors for wineserver (which hits the limit) using 'lsof', one comes across following:
--- snip --- ... wineserve 22122 focht 174r REG 253,1 237568 11036329 /home/focht/.wine/drive_c/Program Files/NeoAxis Engine Non-Commercial SDK 0.58/Game/Bin/OgreNativeWrapper.dll wineserve 22122 focht 175r REG 253,1 237568 11036329 /home/focht/.wine/drive_c/Program Files/NeoAxis Engine Non-Commercial SDK 0.58/Game/Bin/OgreNativeWrapper.dll ... wineserve 22122 focht 1022r REG 253,1 237568 11036329 /home/focht/.wine/drive_c/Program Files/NeoAxis Engine Non-Commercial SDK 0.58/Game/Bin/OgreNativeWrapper.dll wineserve 22122 focht 1023r REG 253,1 237568 11036329 /home/focht/.wine/drive_c/Program Files/NeoAxis Engine Non-Commercial SDK 0.58/Game/Bin/OgreNativeWrapper.dll --- snip ---
Seems "OgreNativeWrapper.dll" is the culprit, hitting the limit.
The PE is mapped as datafile for *each* export (LOAD_LIBRARY_AS_DATAFILE | LOAD_WITH_ALTERED_SEARCH_PATH), giving it different load address:
--- snip --- ... 002f:Call KERNEL32.LoadLibraryExW(02ba7e98 L"C:\Program Files\NeoAxis Engine Non-Commercial SDK 0.58\Game\Bin\OgreNativeWrapper.dll",00000000,0000000a) ret=79e862c8 002f:Ret KERNEL32.LoadLibraryExW() retval=04030001 ret=79e862c8 ... 002f:Call KERNEL32.GetProcAddress(04030001,029cd178 "GuiRendererItemRenderable_Delete") ret=79e84c2d 002f:Ret KERNEL32.GetProcAddress() retval=00000000 ret=79e84c2d 002f:Call KERNEL32.GetProcAddress(04030001,0033d2c1 "GuiRendererItemRenderable_DeleteA") ret=79f7ebd6 002f:Ret KERNEL32.GetProcAddress() retval=00000000 ret=79f7ebd6 ... --- snip ---
I don't know why GetProcAddress() is called for a PE loaded as datafile because it's actually not valid. The module handle seems to be leaked for every entry point lookup, there is never the corresponding FreeLibrary() called. Processing of native image dependencies (imports via PInvoke) is different from dependencies to managed assemblies in .NET core...
Tracking this further down requires a lot of more time ... Currently I leave it as it is (might visit back later) and give the following workaround:
--- snip --- su ulimit -n 4096 su <current username> wine <installer> --- snip ---
After raising the limit, the NI for Renderer.dll assembly is generated. Additionally the installer will now compile a lot more assemblies than before. There is another installer bug at the end, open new bug report for that.
I'm not sure about the "invalid typeref token" stuff because the same kind of warning is emitted while generating native images for several other NeoAxis assemblies. Probably unknown or unhandled CLR metadata - might be harmless.
For the time being, I will add a note to appdb (as super maintainer for .NET), referring to this specific ngen problem, describing workaround.
Regards
http://bugs.winehq.org/show_bug.cgi?id=16258
--- Comment #2 from Anastasius Focht focht@gmx.net 2008-12-15 04:26:49 --- Hello,
I could not resist to dig further otherwise I can't get a good sleep ;-| It turns out this is in fact a bug in the original .NET 2.0 Framework (unpatched/no upgrade/no sp).
The same happens when the ngen worker is compiling the assemblies to native images in virgin XP + original .NET 2.0 Framework. Most likely a bug in handling unmanaged dependencies.
Dumping the list of memory mappings from the compiling process at a certain point showed indeed a large number of mappings of the same file "OgreNativeWrapper.dll" - all having different base addresses. Interestingly process utilities like "process explorer" or "handle/handlex" from the infamous sysinternals team (now M$) don't show the mappings as open file handles. Mysterious...
The standard limit of 1024 open file descriptors bites again... I'll add a workaround (ulimit) to appdb.
Maybe AJ comes up with clever idea but that would most likely require redesign (management of file mappings). I'd suggest to close this as WONTFIX.
Regards
addendum: It might be worthwhile to check .NET 2.0SP1 if it exhibits the same problem - when the SP1 installer is fixed ;-)
http://bugs.winehq.org/show_bug.cgi?id=16258
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX
--- Comment #3 from Dan Kegel dank@kegel.com 2009-08-23 14:58:05 --- Changing to WONTFIX as suggested.
http://bugs.winehq.org/show_bug.cgi?id=16258
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #4 from Dmitry Timoshkov dmitry@codeweavers.com 2009-08-23 22:57:45 --- Closing.
http://bugs.winehq.org/show_bug.cgi?id=16258
--- Comment #5 from Dan Kegel dank@kegel.com 2012-02-23 11:44:27 CST --- Current ubuntu has a higher ulimit -H -n, so the workaround should no longer be needed there.
-
wine-bugs＠winehq.org