https://bugs.winehq.org/show_bug.cgi?id=44246
Bug ID: 44246 Summary: Call of Duty 4: GL_INVALID_OPERATION & GL_OUT_OF_MEMORY Product: Wine Version: 2.21 Hardware: x86 OS: FreeBSD Status: UNCONFIRMED Severity: critical Priority: P2 Component: directx-d3d Assignee: wine-bugs@winehq.org Reporter: hardy.schumacher@gmx.de
Created attachment 60041 --> https://bugs.winehq.org/attachment.cgi?id=60041 Call of Duty 4: console log
When starting "Call of Duty 4" several warn messages can be seen on console.
Shortly after game mode has been entered, warnings from shader can be seen, followed by message: err:d3d:wined3d_debug_callback 0xf8ff878: "GL_INVALID_OPERATION error generated. <program> object is not successfully linked, or is not a program object.".
After several seconds, this message is printed to console: err:d3d:wined3d_debug_callback 0xf8ff878: "GL_OUT_OF_MEMORY error generated. Failed to allocate memory for texture.".
And finally the game and wine instance are crashing.
I'm using FreeBSD-11.1-p3 on AMD64. Wine is from port emulators/i386-wine-devel v2.21. PC is running with NVIDIA driver 340.104. Port graphics/mesa-dri is on v17.3.1.
https://bugs.winehq.org/show_bug.cgi?id=44246
joaopa jeremielapuree@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree@yahoo.fr
--- Comment #1 from joaopa jeremielapuree@yahoo.fr --- Does it happen with the demo https://www.generation-nt.com/demo-call-of-duty-4-telechargement-46162.html
https://bugs.winehq.org/show_bug.cgi?id=44246
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dark.shadow4@web.de Severity|critical |normal
--- Comment #2 from Fabian Maurer dark.shadow4@web.de --- Not a critical bug.
https://bugs.winehq.org/show_bug.cgi?id=44246
Alex S iwtcex@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |iwtcex@gmail.com
--- Comment #3 from Alex S iwtcex@gmail.com --- (In reply to Hardy Schumacher from comment #0)
After several seconds, this message is printed to console: err:d3d:wined3d_debug_callback 0xf8ff878: "GL_OUT_OF_MEMORY error generated. Failed to allocate memory for texture.".
The process might be running out of address space, run top and check the SIZE column.
https://bugs.winehq.org/show_bug.cgi?id=44246
Adrien Fernandes adrien_fernandes2@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |adrien_fernandes2@hotmail.c | |om
--- Comment #4 from Adrien Fernandes adrien_fernandes2@hotmail.com --- Since the original poster seems gone for long now, I'm going to continue this thread.
Three years now I'm having this issue and it has never been fixed. I am a daily FreeBSD user and if this issue could be fixed, I'd be in heaven...
(In reply to joaopa from comment #1)
Does it happen with the demo https://www.generation-nt.com/demo-call-of-duty-4-telechargement-46162.html
Yes it does, I just tried that demo and the higher you set the graphics, the sooner the game freezes or crash and, the same way as Hardy Schumacher, my terminal is filled with GL_INVALID_OPERATION error generated and GL_OUT_OF_MEMORY error generated. Failed to allocate memory for texture.
Here is exactly what I'm using (same hardware for 6 years now) :
- Operating System - FreeBSD 13.0-CURRENT #0 r355406: Thu Dec 5 04:29:02 UTC 2019 (so FreeBSD-CURRENT from the 5th December 2019 img file)
- Physical memory - 12,0G (sure, 32-bits can only use a maximum of 4,0G, I know, but on GNU/Linux too and it always worked so my hardware can not be the problem !)
- Graphic card - GTX 765m
- Video driver - Name : nvidia-driver-390 Version : 390.129
- Wine version - $ wine --version wine-4.21
Clean WINEPREFIX set to WinXP and installed directx 9.0c June 2010 (that 93 MB file) with DXSETUP.exe (instead of winetricks but I always did it this way, even on GNU/Linux and it was working).
(In reply to Alex S from comment #3)
(In reply to Hardy Schumacher from comment #0)
After several seconds, this message is printed to console: err:d3d:wined3d_debug_callback 0xf8ff878: "GL_OUT_OF_MEMORY error generated. Failed to allocate memory for texture.".
The process might be running out of address space, run top and check the SIZE column.
PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 241 Adrien2002 11 21 0 3410M 1022M piperd 2 2:37 212,98% wine
Seems I've reached the maximum amount of 32-bits memory and it makes the game crash but... Why ? How ? Why I can play Call of Duty 4 on GNU/Linux but not on FreeBSD with the exact same hardware ?
https://bugs.winehq.org/show_bug.cgi?id=44246
--- Comment #5 from Alex S iwtcex@gmail.com --- (In reply to Adrien Fernandes from comment #4)
Three years now I'm having this issue and it has never been fixed.
This is actually a somewhat infamous issue and it's much older than that. The usual workaround involves either setting LARGE_ADDRESS_AWARE flag on the executable (which tells Wine to apply a different memory allocation limit) or patching Wine to the same effect. Proton even has a convenient PROTON_FORCE_LARGE_ADDRESS_AWARE environment variable for that matter.
In my experience this workaround results in lower virtual memory allocation by roughly 700 Mb - 1 Gb. It's not clear to me how it does that, it's really not supposed to.
Why I can play Call of Duty 4 on GNU/Linux but not on FreeBSD with the exact same hardware ?
Is there a noticeable difference in virtual memory allocation?
https://bugs.winehq.org/show_bug.cgi?id=44246
--- Comment #6 from Adrien Fernandes adrien_fernandes2@hotmail.com ---
This is actually a somewhat infamous issue and it's much older than that.
Yes, I meant 3 years of Wine on FreeBSD FOR ME and always had this issue so I suppose it is older than 3 years.
Is there a noticeable difference in virtual memory allocation?
Since it always worked like a charm on GNU/Linux, I never investigated it at that time. I remember making a Call of Duty World at War server on Arch Linux and playing it with my cousin and my brother for hours on maximum settings. It was back in 2013 and it was already working well.
But what I remember too is that I already wondered why FreeBSD was acting like that with Wine in 2016. I remember I booted up a Debian live to check and my physical memory for 32-bits was something like 3,0G, not 4,0G (I can confirm if it's an important detail). Wine is not the only affected software. PCSX2 on FreeBSD is also crashing because of "out of memory"
By the way, I forgot to mention my CPU :
- CPU - CPU: Intel(R) Core(TM) i7-4700HQ CPU @ 2.40GHz (2394.51-MHz K8-class CPU)
The usual workaround involves either setting LARGE_ADDRESS_AWARE flag on the executable (which tells Wine to apply a different memory allocation limit) or patching Wine to the same effect. Proton even has a convenient >PROTON_FORCE_LARGE_ADDRESS_AWARE environment variable for that matter.
So what's the next step ? Is there any chance Wine sees the LARGE_ADDRESS_AWARE included in its code for BSD projects (because I suppose NetBSD and OpenBSD experience the same) ? Is the patch available somewhere ? My computer would gladly be used for test purpose. I'm a daily Wine user of FreeBSD.
In my experience this workaround results in lower virtual memory allocation by roughly 700 Mb - 1 Gb. It's not clear to me how it does that, it's really not supposed to.
It lowers the virtual memory allocation, yet it is supposed to make the games not crashing due to memory allocation ? That's an upside down situation !
https://bugs.winehq.org/show_bug.cgi?id=44246
--- Comment #7 from Alex S iwtcex@gmail.com --- (In reply to Adrien Fernandes from comment #6)
Wine is not the only affected software. PCSX2 on FreeBSD is also crashing because of "out of memory"
There is no native PCSX2 port on FreeBSD...
So what's the next step ?
Either you know what to do with that information or you do not. (Hint: google it.)
https://bugs.winehq.org/show_bug.cgi?id=44246
--- Comment #8 from Adrien Fernandes adrien_fernandes2@hotmail.com ---
There is no native PCSX2 port on FreeBSD...
No but you can build it. https://github.com/PCSX2/pcsx2/issues/2042
Either you know what to do with that information or you do not. (Hint: google it.)
Yeah, I guess thats the only way I have for the moment. If the results are satisfying, I really hope to, one day, see the solution added to Wine if it's possible.
I'll patch Wine to try that and I'll come back.
https://bugs.winehq.org/show_bug.cgi?id=44246
--- Comment #9 from Adrien Fernandes adrien_fernandes2@hotmail.com --- So, I gave it a try.
I modified libs/wine/mmap.c
In line 426 :
char *user_space_limit = (char *)0x7ffe0000;
In
char *user_space_limit = (char *)0xbffe0000;
Now, Call of Duty can be run in highest setting without crash and here's what "top" says me while the game is running.
PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 1233 Adrien2002 11 85 0 2521M 1223M CPU4 4 2:16 242,00% wine
It is ~900M lower than before. I don't understand why it works. I can understand now the game isn't crashing anymore but why it can run with almost 1G less or why it was running with 1G more, before the modification of mmap.c ?
Can that "fix" cause issue in graphics compared to GNU/Linux's Wine ?
https://bugs.winehq.org/show_bug.cgi?id=44246
--- Comment #10 from Alex S iwtcex@gmail.com --- (In reply to Adrien Fernandes from comment #9)
So, I gave it a try.
I modified libs/wine/mmap.c
In line 426 :
char *user_space_limit = (char *)0x7ffe0000;In
char *user_space_limit = (char *)0xbffe0000;
I was talking about the limits in dlls/ntdll/virtual.c, but that is definitely interesting.
It is ~900M lower than before. I don't understand why it works. I can understand now the game isn't crashing anymore but why it can run with almost 1G less or why it was running with 1G more, before the modification of mmap.c ?
The application doesn't run with 1 Gb less memory, some Wine component _asks_ for less memory from the OS. It still uses the same amount of memory as before. You see, address ranges are reserved immediately, while the physical memory is allocated in pages on actual access. That 1 Gb was never read/written in the first place, as you can clearly see from the resident memory value in top.
Can that "fix" cause issue in graphics compared to GNU/Linux's Wine ?
It's just a game. Worst case it crashes and corrupts your saves.
https://bugs.winehq.org/show_bug.cgi?id=44246
--- Comment #11 from Adrien Fernandes adrien_fernandes2@hotmail.com ---
The application doesn't run with 1 Gb less memory, some Wine component _asks_ for less memory from the OS. It still uses the same amount of memory as before. You see, address ranges are reserved immediately, while the physical memory is allocated in pages on actual access.
I'm trying to understand how it works. Wine allocates memory in the first place which is a fixed amount, whatever you use under Wine ? Like when you create a virtual disk with VirtualBox and ask for the disk to actually TAKE the size you set directly, without to wait to really write something in it (fixed size) ?
So how an application works then. Does it run inside the allocated space ? Or on the side ? When I run "winecfg", I have this :
PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 1345 Adrien2002 4 25 0 1520M 27M piperd 1 0:00 0,00% wine
Even if I can see 27M on RES, I still see 1520 allocated by Wine, it corresponds to what you said.
That 1 Gb was never read/written in the first place, as you can clearly see from the resident memory value in top.
Yes, I see ~1020M of RES on both "top" I saved.
I was talking about the limits in dlls/ntdll/virtual.c, but that is definitely interesting.
As you certainly guessed, I'm not a developer and my knowledges aren't great. I usually try to do things by myself which is the best way to learn. I Googled for a solution, reading many topics and articles to understand then apply and that "solution" I found (which may not be a solution, I don't know), is what I guessed was the solution. If I open a file as big as virtual.c, I'll just stand in front of the screen, wondering what can be done.
I used the search function of vim to find, starting at line 2544, a section speaking about LARGE_ADDRESS_AWARE but I didn't touch it yet since I wouldn't know how to without to risk to break everything. Also, this thread here https://bugs.winehq.org/show_bug.cgi?id=33858 makes me wonder if my problem is really about the LARGE_ADDRESS_AWARE and not about Wine eating, exclusively, too much on FreeBSD. The people in the thread say it's not a solution either to globally change it and make every applications run with LAA since it may break some applications. Is my problem really related to LAA ? Cause I didn't apply LAA to Wine nor to any Windows executable but I can run Assassin's Creed and Call of Duty now, just like in GNU/Linux, with the solution I found and apply.
But it would not make Far Cry 3 @ ultra settings works I suppose (which is the topic of the thread I just shared with you). In the best case, I will have a normal behavior of Wine, like in GNU/Linux and I would need my solution AND to apply LAA to Far Cry 3 executable if I want to run it in ultra settings.
I have a Dell Inspiron with Arch Linux. I don't use it to play but I installed Wine and checked the memory allocated by Wine when I run winecfg :
PID UTIL. PR NI VIRT RES SHR S %CPU %MEM TEMPS+ COM. 693 adrien2+ 20 0 1747,0m 15,8m 9,6m S 0,3 0,2 0:00.70 winedevice.exe
It's close to FreeBSD. Is it interesting and useful here ?
Sorry if I'm totally mistaken and didn't get anything correctly.
In any case, thank you very much for taking time to answer and explain how things work, I appreciate it and I wish this thread can help other FreeBSD users to play their bigger games.
https://bugs.winehq.org/show_bug.cgi?id=44246
Neko-san nekoNexus@protonmail.ch changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nekoNexus@protonmail.ch
-
wine-bugs＠winehq.org -
WineHQ Bugzilla