http://bugs.winehq.org/show_bug.cgi?id=16456
--- Comment #51 from Jeffrey Bonggren 7wtjvu302@sneakemail.com 2009-03-30 18:09:56 --- (In reply to comment #47)
(In reply to comment #45) I believe the issue is not with system memory, but with graphic memory.
Given that doug's patch (the first attachment above) fixes the GL_OUT_OF_MEMORY error (at the expense of leaking system memory), I agree this must be a GL resource management issue.
I have been troubleshooting this error with the assumption that the bug is in (or is triggered by code in) wine/dlls/d3d9. I suppose the bug could possibly be in the Linux NVIDIA drivers, but I have no other OpenGL driver to test this theory with. Plus, troubleshooting closed-source code is no fun!
My strategy has been to use BuGLe to monitor the GL resource usage of SoaSE in wine. BuGLe works by using LD_PRELOAD to override all of the GL symbols with its own. The LD_PRELOAD doesn't work with Wine, but I was able to build wine/dlls/opengl32 while directly linking against libbugle.so instead of libGL. libbugle is supposed to communicate via pipe with a GUI that can show me what is going on.
The GUI is started on the cmdline similarly to wine. You run the GUI and pass the target program's name and its args as its parameters. The GUI does a pipe()-dup()-fork()-exec() to create the pipe and run the target program.
I run it like this: /usr/local/bin/gldb-gui ~/wine-git/wine ""Sins of a Solar Empire.exe""
The GUI starts up; I select the Run command; it starts Wine SoaSE. SoaSE runs like normal, but I never see anything in the BuGLe GUI. I assume that Wine is somehow interfering with the passing of the pipe, but I haven't spent the time to figure it out.
Has anyone else out there tried to use BuGLe with Wine?