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