https://bugs.winehq.org/show_bug.cgi?id=46675
--- Comment #16 from tjb troyb@us.ibm.com --- (In reply to Zebediah Figura from comment #15)
(In reply to tjb from comment #14)
I ran in Win7 and it looks like you are right, it was up to 2000 handles in 20 minutes, same leak rate as under wine. I guess all I can do is to try to kludge in some kind of a timestamp based stale handle recovery queue into ntdll to run it on wine.
Well, maybe. I see two better options: (a) since the program seems to be opening the same file, find some way to map multiple handles to the same fd, or (b) just raise your NOFILE limits.
Yes, the NOFILE is the ticket here :
cat /proc/sys/fs/file-max 6577327
Shows my system is capable of 6.5M open files total (I have a 64G main mem rig).
I then change to root in a terminal, do a ulimit -Hn 1000000 , su to my user in the uplimited root shell, ulimit -Sn 1000000 as me and the game ran fine for 40+ minutes so I think it took. This is most likely the only realistic option to run the game without getting into some crazy hackage inside of wine to try to compensate the program's handle leaks, unless it was a common problem on multiple games and they all make the same class of mistake it is not worth investing programming time to try to compensate it.
Thanks a lot for your help... I think this bug report can now be closed, it is positive IDed as a program problem and not a wine bug.