http://bugs.winehq.org/show_bug.cgi?id=26292
Summary: OpenGL_Out_of_Memory (505). There's a leak in the ARB_Vertex_Buffer_Object Product: Wine Version: 1.3.14 Platform: x86-64 OS/Version: Mac OS X 10.6 Status: UNCONFIRMED Severity: critical Priority: P2 Component: opengl AssignedTo: wine-bugs@winehq.org ReportedBy: rochondil@gmail.com
Created an attachment (id=33520) --> (http://bugs.winehq.org/attachment.cgi?id=33520) My last run winelog for the beefy details
Basically it looks like Wine is trying to create a buffer on an already mapped VBO...Which means. The real problem seems to me that the memory handling is the problem. Wine can't clean the buffer properly and when it tries to create a new buffer it fails thus being forced to use the mapped vbo which gradually fills up then leaks. It is not pretty.
The bug is occurring in "Oblivion GOTY". And I have tested x amount of different settings though please come up with new ones (i.e. not those already mentioned in the oblivion/fallout etc. threads.) I do believe though that this can be fixed by implementing the same fix as cedega does by limiting the GL Extension buffer to "-GL_ARB_vertex_buffer_object". I know this works in cedega and cider. And I know Wine and cedega doesn't exchange code (if they did I would have solved it already). The thing is cedega is on to something with the GL extension and I have no idea how to make it fixed in Wine. Adding a disabledextensions in OpenGL key in Wine registry does not work; the same error shows up.
I am using a mid 2009 MBP 15". My GFX GeForce 9600M GT 512 and my CPU 2.8GHz with 4GB DDR3 Ram. I run the latest OSX. My wine is doh123s compiled Wineskin Wrapper and I am running OBSE in Oblivion however it does not matter wether I run with it or without. The game crashes once the leak is to heavy. Furthermore it is easily recreated by running a lot of mods and high graphics along with running around in a dense polygon area or somewhere with a lot of stuff that needs rendering, thus the buffer is filled quickly. Believe it or not the crash seems to occur at a slower rate when running in debug mode and it is also possible to purge the cell buffers in game so that the in-game time may be extended even further before a critical leak occurs.
I would love to fix this. I believe it is rather easy to fix. Just a needed injection in the registry should be all.
Any thoughts?
PS: I have added my error log for a bit more meat on the bones.
http://bugs.winehq.org/show_bug.cgi?id=26292
--- Comment #1 from Henri Verbeet hverbeet@gmail.com 2011-03-03 13:10:19 CST --- What makes you think this is a resource leak in Wine, instead of the usual OS X address space exhaustion?
http://bugs.winehq.org/show_bug.cgi?id=26292
--- Comment #2 from iAmbrosius rochondil@gmail.com 2011-03-03 13:34:47 CST --- (In reply to comment #1)
What makes you think this is a resource leak in Wine, instead of the usual OS X address space exhaustion?
Huh... That might be true! I didn't think about that... But why would it be the OS X address space exhaustion? I mean I am not able to recreate the crash at all using a cider wrapper. The cedega in Cider manages to keep the address space trimmed or so to say it manages to clean the vbo properly..
http://bugs.winehq.org/show_bug.cgi?id=26292
Juan Lang juan_lang@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|critical |normal
--- Comment #3 from Juan Lang juan_lang@yahoo.com 2011-03-03 13:36:48 CST --- Not critical: http://bugs.winehq.org/page.cgi?id=fields.html#bug_severity
http://bugs.winehq.org/show_bug.cgi?id=26292
--- Comment #4 from iAmbrosius rochondil@gmail.com 2011-03-03 21:54:02 CST --- (In reply to comment #3)
Not critical: http://bugs.winehq.org/page.cgi?id=fields.html#bug_severity
Oh sorry. I will be more observant next time!
http://bugs.winehq.org/show_bug.cgi?id=26292
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|OpenGL_Out_of_Memory (505). |Oblivion GOTY: |There's a leak in the |OpenGL_Out_of_Memory (505) |ARB_Vertex_Buffer_Object |
http://bugs.winehq.org/show_bug.cgi?id=26292
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- OS/Version|Mac OS X 10.6 |Mac OS X
http://bugs.winehq.org/show_bug.cgi?id=26292
--- Comment #5 from Ilya Kuryanov exeman888@gmail.com 2011-11-13 15:40:09 CST --- Created attachment 37487 --> http://bugs.winehq.org/attachment.cgi?id=37487 A sample log of wine running TES V: Skyrim with texture detail set to 'high'
Exactly the same bug is present in Skyrim. If you set texture detail to 'high', you will hardly be able to start the game — it will freeze with OpenGL_Out_of_Memory in logs. If you set it to 'medium', you'll be able to play, but the game will inevitably freeze sometime later with the same error. Attached is an example of a log you get with high texture detail. I don't have a copy of Cider, so I can't check if the bug is present there, and anyway, that would be somewhat irrelevant.
http://bugs.winehq.org/show_bug.cgi?id=26292
Evan Goers megatog615@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |megatog615@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=26292
Thomas Luquet thomas@luquet.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |thomas@luquet.net
http://bugs.winehq.org/show_bug.cgi?id=26292
Ahmed W. oneofone@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |oneofone@gmail.com
--- Comment #6 from Ahmed W. oneofone@gmail.com 2011-11-15 18:34:11 CST --- I can confirm this bug with Skyrim as well.
http://bugs.winehq.org/show_bug.cgi?id=26292
--- Comment #7 from Ahmed W. oneofone@gmail.com 2011-11-15 20:31:36 CST --- Created attachment 37503 --> http://bugs.winehq.org/attachment.cgi?id=37503 Skyrim log on ultra high
This is on Arch Linux (64bit) -> wine-git --version wine-1.3.32-205-g5c732d7 -> uname -r 3.1.0-4-ARCH -> cat /proc/driver/nvidia/gpus/0/information Model: GeForce GTX 285
http://bugs.winehq.org/show_bug.cgi?id=26292
TRiToNa-Ma jedi.orden@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jedi.orden@gmail.com
--- Comment #8 from TRiToNa-Ma jedi.orden@gmail.com 2011-11-16 06:53:00 CST --- I also confirm this bug when running Skyrim. I found that on ultra high shadow-settings all crashes before the start of the game (play, not menu), with the lowest shadows all playable for 15-20 minutes, afterwards the same error occur.
http://bugs.winehq.org/show_bug.cgi?id=26292
Ilya Kuryanov exeman888@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |exeman888@gmail.com
--- Comment #9 from Ilya Kuryanov exeman888@gmail.com 2011-11-16 10:05:04 CST --- I found that specifying the amount of memory your video card has (videomemorysize=x, settable in Winetricks as well) , helps to increase the time amount you can spend in-game before the game freezes or make it work on higher settings. Please, try this out and say if it works for you too.
http://bugs.winehq.org/show_bug.cgi?id=26292
Bartosz bartek@core-t.pl changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bartek@core-t.pl
--- Comment #10 from Bartosz bartek@core-t.pl 2011-11-26 03:30:51 CST --- I confirm that setting shadows on ultra high in Skyrim causes crash when loading saved game becase of GL_OUT_OF_MEMORY (0x505) error.
@Ilya Kuryanov Setting memory size does not help.
Gentoo amd64 wine 1.3.32 NVIDIA GTX 560 with 1024MB of RAM
http://bugs.winehq.org/show_bug.cgi?id=26292
--- Comment #11 from Bartosz bartek@core-t.pl 2011-11-26 03:32:36 CST --- Created attachment 37631 --> http://bugs.winehq.org/attachment.cgi?id=37631 wine output width ultra high shadows
http://bugs.winehq.org/show_bug.cgi?id=26292
Delporte caffeine@calneva.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |caffeine@calneva.org
--- Comment #12 from Delporte caffeine@calneva.org 2011-11-26 11:23:41 CST --- Not sure if this is helpful or not but thought I'd throw it out there. I also get an immediate GL_OUT_OF_MEMORY (0x505) error when playing with all settings on high--and can also confirm that setting shadows to anything other then 'low' seems to be a main culprit. So while messing around on Google trying to find out why the latest patch made the game significantly more unstable (another issue entirely) I came across some posts mentioning that you can make the TESV.exe LAA (Large Address Aware) so that It can address >2GB of memory.
If you don't have the latest patch you can use these instructions to make your TESV.exe Large Address Aware --> http://www.skyrimnexus.com/downloads/file.php?id=134&navtag=file/images.... .
If however you do have the latest patch and don't have a copy of the original exe laying around you will need to go this route (I couldn't get it to work)--> http://www.skyrimnexus.com/downloads/file.php?id=1013#content. This is because the update made it so that steam can no longer be bypassed by running TESV.exe directly and Steam also checks the integrity of TESV.exe. This method is suppose to let Steam verify the EXE and THEN inject the LAA code. Again, I couldn't get this method to work.
I ended up finding a copy of the original EXE and used the first method.
Anyway, my point? making the EXE Large Address Aware I was able to play for more than 30 minutes with all settings at max and with no crashes, Out Of Memory or otherwise (I quite because I had to go do some things so I'm not sure how long it will last this way).
I'm not sure if this helps diagnose the problem in any way or if I'm just masking the crash by throwing more memory at the game but just thought I'd share.
BTW I'm running 64Bit Gentoo and I'm running the game from a 64Bit WINEPREFIX and my rig has 16GB or ram.
If this is irrelevant info then let me know and if so, sorry for the wasted space
http://bugs.winehq.org/show_bug.cgi?id=26292
--- Comment #13 from Bartosz bartek@core-t.pl 2011-11-26 15:57:00 CST --- (In reply to comment #12)
Not sure if this is helpful or not but thought I'd throw it out there. I also get an immediate GL_OUT_OF_MEMORY (0x505) error when playing with all settings on high--and can also confirm that setting shadows to anything other then 'low' seems to be a main culprit. So while messing around on Google trying to find out why the latest patch made the game significantly more unstable (another issue entirely) I came across some posts mentioning that you can make the TESV.exe LAA (Large Address Aware) so that It can address >2GB of memory.
If you don't have the latest patch you can use these instructions to make your TESV.exe Large Address Aware --> http://www.skyrimnexus.com/downloads/file.php?id=134&navtag=file/images.... .
If however you do have the latest patch and don't have a copy of the original exe laying around you will need to go this route (I couldn't get it to work)--> http://www.skyrimnexus.com/downloads/file.php?id=1013#content. This is because the update made it so that steam can no longer be bypassed by running TESV.exe directly and Steam also checks the integrity of TESV.exe. This method is suppose to let Steam verify the EXE and THEN inject the LAA code. Again, I couldn't get this method to work.
I ended up finding a copy of the original EXE and used the first method.
Anyway, my point? making the EXE Large Address Aware I was able to play for more than 30 minutes with all settings at max and with no crashes, Out Of Memory or otherwise (I quite because I had to go do some things so I'm not sure how long it will last this way).
I'm not sure if this helps diagnose the problem in any way or if I'm just masking the crash by throwing more memory at the game but just thought I'd share.
BTW I'm running 64Bit Gentoo and I'm running the game from a 64Bit WINEPREFIX and my rig has 16GB or ram.
If this is irrelevant info then let me know and if so, sorry for the wasted space
This is very helpful I used tutorial on this page: http://www.skyrimnexus.com/downloads/file.php?id=134 and now I can use ultra high shadows, game looks awesome and runs smoothler I think that you solved that bug, thanks
http://bugs.winehq.org/show_bug.cgi?id=26292
Vitaliy Margolen vitaliy-bugzilla@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |INVALID
--- Comment #14 from Vitaliy Margolen vitaliy-bugzilla@kievinfo.com 2011-11-26 21:11:29 CST --- Looks like invalid bug then, if users on Windows have the same issue.
http://bugs.winehq.org/show_bug.cgi?id=26292
--- Comment #15 from Delporte caffeine@calneva.org 2011-11-26 22:17:19 CST --- I was thinking this might be more of a workaround to the original problem since Windows users don't technically *NEED* a Large Address Aware executable for the game to at least load and run with all settings on High. My nephew is running windows 7 ultimate and can run the game for some time without this hack and with all settings at max before it crashes. Under wine, and without this hack, the Out Of Memory problem presents immediately. I know there are crashes for this game on Windows also but its hard to say if its the same issue. Maybe someone who knows more about this sort of thing can shed some light?
As !Ambroisius has pointed out I also have had this issue with Oblivion and Fallout 3 so it is entirely possible that this could be a Bethesda specific game engine problem that is specific to wine. I'm not a programmer so I could be completely off base here.
I will point out that before the Steam patch I could run the game for hours on end as long as I had the Shaders set to 'Low' but after the Steam patch it would freeze, lock up, not load areas, etc. at random times which is also what Windows users experienced after the update. So is there any way to tell if all this is related?
I only chime in in case this solution doesn't work for all people or stops working with future patches to the game.
I guess time will tell if this is truly an INVALID bug or if there is an underlying issue.
Unfortunately I'm not well versed in programming so have no real skills to test any of this but thought I'd throw some thoughts out there.
Thanks
http://bugs.winehq.org/show_bug.cgi?id=26292
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #16 from Austin English austinenglish@gmail.com 2011-11-29 15:47:48 CST --- Closing.