[Bug 16258] New: .net 2.0's ngen.exe hangs while compiling a particular assembly
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(a)winehq.org ReportedBy: dank(a)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 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16258 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |focht(a)gmx.net --- Comment #1 from Anastasius Focht <focht(a)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 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16258 --- Comment #2 from Anastasius Focht <focht(a)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 ;-) -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16258 Dan Kegel <dank(a)kegel.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX --- Comment #3 from Dan Kegel <dank(a)kegel.com> 2009-08-23 14:58:05 --- Changing to WONTFIX as suggested. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16258 Dmitry Timoshkov <dmitry(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #4 from Dmitry Timoshkov <dmitry(a)codeweavers.com> 2009-08-23 22:57:45 --- Closing. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16258 --- Comment #5 from Dan Kegel <dank(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
participants (1)
-
wine-bugs＠winehq.org