2017-06-06 17:35 GMT+02:00 Akihiro Sagawa sagawa.aki@gmail.com:
On Mon, 5 Jun 2017 19:41:06 +0200, Matteo Bruni wrote:
2017-06-05 16:15 GMT+02:00 Akihiro Sagawa sagawa.aki@gmail.com:
On Sun, 4 Jun 2017 22:51:10 -0600, Alex Henrie wrote:
Out of curiosity, is there a particular application that depends on this behavior? It could be argued that reporting the value from the native operating system is better because it tells what's really happening in the process.
-Alex
Good question. I'm trying to fix Sorcery Jokers (trial) issue, bug 43119. The application repeatedly trys to allocate virtual memory as much as possible, and measures available memory size by GlobalMemoryStatusEx().
This patch is better than nothing. The application stops memory allocation about 384MB (0x17ffffff) free. After the allocation, it succeeds to load libGL.so. However, it shows driver pointer missing error when loading DRI driver, radeonsi_dri.so. I'm still in trouble with this point.
By the way, I have another idea about this issue. That is reserving virtual memory area when loading wined3d.dll and release it just before loading OpenGL libraries. Being hackish idea, I chose the forementioned method in the beginning.
As far as hacks go, does adding some arbitrary "reserved" amount to pvmi.VirtualSize make any difference?
Thanks comments. Could you explain why adding "reserved" amount to pvmi.VirtualSize helps the issue? From my viewpoint, if we increase pvmi.VirtualSize, available virtual memory, i.e. MEMORYSTATUSEX.ullAvailVirtual, will decline. And, VM allocation limit doesn't change.
As I understood your previous email, it sounded like the application allocates memory until the free memory amount gets to some particular value. By "faking" a lower free memory amount the application might stop allocating earlier and leave enough addressing space for native libraries.
Does it make sense? Did I misunderstand something?