[Bug 45045] New: Vampire: The Masquerade Bloodlines, GL_OUT_OF_MEMORY, worked in wine 1.8
https://bugs.winehq.org/show_bug.cgi?id=45045 Bug ID: 45045 Summary: Vampire: The Masquerade Bloodlines, GL_OUT_OF_MEMORY, worked in wine 1.8 Product: Wine Version: 3.6 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: ckoe_(a)web.de Distribution: --- Created attachment 61172 --> https://bugs.winehq.org/attachment.cgi?id=61172 Console outputs and backtraces for different videomemorysize settings. Hello everybody, I would like to report a crash of Vampire: The Masquerade Bloodlines (VTMB) upon or shortly after loading of a saved game just after a fresh start of the main game and/or area transition. It worked fine with wine 1.6 (debian jessie) and the wine 1.8 from debian 9 (stretch, stable). It crashes with wine 3.0 and wine 3.6 as detailed below. The crash might be related to https://bugs.winehq.org/show_bug.cgi?id=42732 and it has superficial similarities to https://bugs.winehq.org/show_bug.cgi?id=24701 but because it worked for me without problems in the earlier wine versions mentioned above I believe 24701 can be ruled out and I would like to file a new bug report explicitely. Please feel free to eventually mark as duplicate as appropriate. I have some hope that it might help people with the same problem anyway if they can find it. The VTMB in question is the version distributed by GOG including the Unoffical Patch version 9.7 by wesp5 as distributed by GOG (plus some additional textures). The OS is debian 9 (stretch, stable) on a Haswell with IGP HD4400, before upgrading I ran it on debian jessie (8, old-stable) on the same hardware. Again: No problems were observed with wine 1.6 and wine 1.8. With wine 3.0 and wine 3.6 (I will only report/attach wine 3.6 details below) I now observe a memory usage related crash upon (usually) loading of a saved game and/or area transition depending on "winetricks videomemorysize=". The game was newly started each time, i.e. it does not crash after hours of playing but basically immediately. I see on the console 0038:err:d3d:wined3d_debug_callback 0x1ba070: "GL_OUT_OF_MEMORY in ... before it crashes. I attached the console outputs and backtraces for various videomemorysize settings, i.e. default, 512, 1024, 2048. They do not make a noticeable difference. I then set LARGE_ADDRESS_AWARE as suggested in 42732 on vampire.exe. With this modified binary I could not observe any problems when loading saves or doing area transitions, but I tested it only for a few minutes. Still, this is an obvious change. So, in summary some change in wine after wine 1.8 might have broken that game by somehow changing the memory layout. Please let me know if I should gather any additional information. Best Regards Christof P.S.: I tried to submit the same bug previously but it somehow never showed up in the bug list. Not sure what happened. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=45045 --- Comment #1 from ckoe_(a)web.de --- Correction: transition depending on "winetricks videomemorysize=" should read transition not depending on "winetricks videomemorysize=" -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=45045 joaopa <jeremielapuree(a)yahoo.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree(a)yahoo.fr --- Comment #2 from joaopa <jeremielapuree(a)yahoo.fr> --- To have a good chance to see the bug fixed, you should do a regression test: https://wiki.winehq.org/Regression_Testing And the usual question: is there a freely downloadable demo showing the problem. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=45045 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=45045 tokktokk <fdsfgs(a)krutt.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fdsfgs(a)krutt.org -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=45045 --- Comment #3 from ckoe_(a)web.de --- Hello everybody, no, there (unfortunately) is no free reproducer. I am aware that this might make it unfixable without detailed regression test but hoped that full regression testing could be avoided somehow. I once built wine from source on a workstation and hunting down and installing the dependencies took half a day or so and I believe compiling was another hour or two. I fear that this is not good on a laptop, especially as the SSD is low on free space and write endurance. However, I notice that winehq has debian packages as far back as 2.0 (as far as I could see all of them in a stretch version). Would it be helpful to try these package releases one after the other as a first step ? Bisecting on the commit granularity could be done later. I would have to move that to a VM on a "real" computer anyway. So the preparation will take quite some time I am afraid. In any case thank you for your interest and effort ! Best Regards Christof -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=45045 --- Comment #4 from joaopa <jeremielapuree(a)yahoo.fr> --- So, the bug does not occur with https://www.fileplanet.com/46322/download/Vampire:-The-Masquerade-Redemption... ? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=45045 --- Comment #5 from ckoe_(a)web.de --- Created attachment 61186 --> https://bugs.winehq.org/attachment.cgi?id=61186 Console log and backtrace with 1.8, vidoememorysize=default -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=45045 --- Comment #6 from ckoe_(a)web.de --- Hello everybody, I discovered that the newest saves from the 3rd playthrough are from February 4th. So they are quite old. I reinstalled wine 1.8 then to make sure everything was as I assumed it was and it turns out that it now also runs out of memory with wine 1.8 ... err:d3d:wined3d_debug_callback 0x210b68: "GL_OUT_OF_MEMORY in glMapBufferRange(map failed)". On the other hand it must have worked on some point as I have late game saves from two complete previous playthroughs. It might be that I only played it with wine 1.6 from jessie. On the other hand I have a lvm.conf.dpkg-new dated February 1st which would hint that it is that date on which I upgraded to stretch. In that case the February 4th saves should be with wine 1.8. I uploaded a console log and backtrace with wine 1.8. I am very confused now and I would like to apologize for apparently not testing thoroughly enough. If I find a way to install wine 1.6 from jessie on the current OS I will try that. Eventually this is more OS/i915 driver related than it is wine related and this should be ruled out first of course. Testing in a VM might yield some clues. If you have any more input on how to procede I would appreciate it. I will report back in any case. Please note that Redemption is a completely different game from a different company with a different game engine, just using the same game license. Bloodlines uses an early Source Engine (-> Half Life 2). So trying that demo does not make sense. Best Regards Christof -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=45045 --- Comment #7 from ckoe_(a)web.de --- Hello again, now I am back on wine 3.6 and tried to load different saves. As it turns out one indoor save can be loaded and it is playable (inside a single area, you cannot easily leave because it is end game). The save I used for the original report, which is the newest save I have and also indoors, still does crash in the same way. I alsoe found one where the game crashes reliably on area transition from indoors to outdoors. I assume this depends on the order/amount of game data to be loaded into memory. The one which crashes on area transition gives in the console 0059:err:d3d:wined3d_resource_allocate_sysmem Failed to allocate system memory. which I believe is a new one. I will think about how to come to a conclusion on this tomorrow. Best Regards Christof -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=45045 --- Comment #8 from ckoe_(a)web.de --- Created attachment 61190 --> https://bugs.winehq.org/attachment.cgi?id=61190 Backtrace with wine 1.6 from jessie running on stretch -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=45045 --- Comment #9 from ckoe_(a)web.de --- Hello everyobody, I have to admit defeat with this at least for the moment.
From various file creation dates on the system I am sure that the upgrade from jessie to stetch happened on February 1st. And then I played it on February 4th for several hours producing several saves. That must have been with wine 1.8. So it must have worked.
I now installed the jessie wine 1.6 (wine32) packages on top of the stretch system. And: even with wine 1.6 it crashes at the same points. A backtrace (top is 0 0x5631ff0c in i965_dri.so) is attached. So I have to admit that I am no longer able to reproduce the condition in which it worked to begin with. This probably indicates that wine is not the problem but some other factor. I am not sure if I will be able to identify it. Because of this you may close this bug report either as invalid or, if you prefer, leave it open and I will report if I happen to be able either to reach the working state again and/or what happens in a VM (different graphics driver etc.). Thank you very much for your interest and my apologies again for not testing thoroughly enough right at the start but just assuming it was the wine version. Best Regards Christof -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=45045 Matteo Bruni <matteo.mystral(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #10 from Matteo Bruni <matteo.mystral(a)gmail.com> --- I'm resolving this as INVALID for now, but feel free to reopen if you find new info (e.g. you figure out it's a Mesa regression, or whatever happens.) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=45045 --- Comment #11 from ckoe_(a)web.de --- Hello, OK, great ! One small bit of info: The modified exe with LARGE_ADDRESS_AWARE set continous to just work. The modified exe uses about VSZ 2.2 GByte/ RSS 680 MByte after loading a safe. The original exe at the time it crashes is using VSZ 3.1 GByte/ RSS 220 MByte. Best Regards Christof -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=45045 André H. <nerv(a)dawncrow.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED CC| |nerv(a)dawncrow.de --- Comment #12 from André H. <nerv(a)dawncrow.de> --- closing invalid -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
wine-bugs＠winehq.org