[Bug 16258] .net 2.0's ngen.exe hangs while compiling a particular assembly

[wine-bugs at winehq.org]

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


Anastasius Focht <focht at gmx.net> changed:

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




--- Comment #1 from Anastasius Focht <focht at 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.