[Bug 53737] New: Incoming (game): crashes after the intro video
https://bugs.winehq.org/show_bug.cgi?id=53737 Bug ID: 53737 Summary: Incoming (game): crashes after the intro video Product: Wine Version: 7.18 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: putr4.s(a)gmail.com Distribution: --- Created attachment 73174 --> https://bugs.winehq.org/attachment.cgi?id=73174 Terminal output of GOG version Recently with an update in the Wine 7.x series (don't know which one unfortunately, but it worked with 7.x at some point) the game Incoming no longer runs, it shows the intro video and music, but then the music stops and it crashes on either a black screen or the loading screen while the Wine crash reporter appears in the background. I was using the GOG version of Incoming, but the demo (the same one mentioned in bug 44864, MD5: 5b1fff6863768eeff95167e510d09a2e, SHA256: dcc55a269c33ea5363cd937284752d7ffe57f4774c55a38dfdd4a9172376563c, 3.8MB file called incoming.exe, available via cnet.com at least) also exhibits the same issue. I have attached the terminal output from the GOG version as log.txt, and I will also attach the terminal output of the GOG version as well as the demo versions of those two. The wine version I am using is from the Arch Linux repositories, and I am using a clean 64 bit wineprefix with no settings changed at all (this setup worked fine before), although I also tried a 32 bit wineprefix, same results. OpenGL vendor string: Intel OpenGL renderer string: Mesa Intel(R) HD Graphics 530 (SKL GT2) OpenGL core profile version string: 4.6 (Core Profile) Mesa 22.1.7 OpenGL core profile shading language version string: 4.60 OpenGL version string: 4.6 (Compatibility Profile) Mesa 22.1.7 OpenGL shading language version string: 4.60 -- 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=53737 --- Comment #1 from Prajna Sariputra <putr4.s(a)gmail.com> --- Created attachment 73175 --> https://bugs.winehq.org/attachment.cgi?id=73175 Terminal output of demo version -- 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=53737 --- Comment #2 from Prajna Sariputra <putr4.s(a)gmail.com> --- Created attachment 73176 --> https://bugs.winehq.org/attachment.cgi?id=73176 Backtrace from the crash reporter (GOG version) -- 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=53737 --- Comment #3 from Prajna Sariputra <putr4.s(a)gmail.com> --- Created attachment 73177 --> https://bugs.winehq.org/attachment.cgi?id=73177 Backtrace from the crash reporter (demo version) -- 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=53737 Béla Gyebrószki <gyebro69(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gyebro69(a)gmail.com URL| |https://archive.org/downloa | |d/incoming_201401/incoming. | |exe Keywords| |download, regression --- Comment #4 from Béla Gyebrószki <gyebro69(a)gmail.com> --- Please run a regression test: https://wiki.winehq.org/Regression_Testing Incoming demo (to reproduce the problem): https://archive.org/download/incoming_201401/incoming.exe incoming.exe (3.8M) md5: 5b1fff6863768eeff95167e510d09a2e -- 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=53737 --- Comment #5 from Prajna Sariputra <putr4.s(a)gmail.com> --- Created attachment 73225 --> https://bugs.winehq.org/attachment.cgi?id=73225 Terminal output (demo, git master commit 001665d7354ca9a21de0d2a5cbfe0839e92446cd) -- 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=53737 --- Comment #6 from Prajna Sariputra <putr4.s(a)gmail.com> --- Created attachment 73226 --> https://bugs.winehq.org/attachment.cgi?id=73226 Backtrace (demo, git master commit 001665d7354ca9a21de0d2a5cbfe0839e92446cd) -- 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=53737 Prajna Sariputra <putr4.s(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Version|7.18 |7.7 --- Comment #7 from Prajna Sariputra <putr4.s(a)gmail.com> --- Bisect reports that dfd5f109fb4ebad859bf3ce3960b3b2b2ad1341d ("ntdll: Increase kernel stack size.", dated 13 Apr) is the first bad commit. However, while reverting that on top of 7.7 does make it work doing so does not fix the crash on git master. The backtrace at least looks different on master though, so I have uploaded that plus the terminal output for master as well. In short, here is what I tested: 7.6: ok 7.7: fail 7.7 minus dfd5f109fb4ebad859bf3ce3960b3b2b2ad1341d: ok master at 001665d7354ca9a21de0d2a5cbfe0839e92446cd: fail master minus dfd5f109fb4ebad859bf3ce3960b3b2b2ad1341d: fail -- 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=53737 Zeb Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |pgofman(a)codeweavers.com Regression SHA1| |dfd5f109fb4ebad859bf3ce3960 | |b3b2b2ad1341d -- 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=53737 --- Comment #8 from Paul Gofman <pgofman(a)codeweavers.com> ---
From the log:
010c:err:d3d:wined3d_resource_allocate_sysmem Failed to allocate system memory.
While blaming that commit which increased kernel stack size is not random (it increased the amount of VRAM used per thread), it is noted in the previous comment that it doesn't help anymore on top of current master (so unless it is an unrelated regression some other changes also increased VRAM usage for the game). It would be great to see the log with the commit reverted on top of git master to confirm if that is the same VRAM exhaustion issue. I am not sure if we can do anything sensible about it now, I don't have immediate feasible ideas how we can deal with variable kernel stack size (and I think reverting it to the older size will break more than fix). Long term with 32 on 64 that shouldn't be an issue as kernel stack is going to be 64 bit. -- 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=53737 --- Comment #9 from Paul Gofman <pgofman(a)codeweavers.com> --- (In reply to Paul Gofman from comment #8)
From the log:
I am not sure if we can do anything sensible about it now, I don't have immediate feasible ideas how we can deal with variable kernel stack size (and I think reverting it to the older size will break more than fix). Long term with 32 on 64 that shouldn't be an issue as kernel stack is going to be 64 bit.
Here I mean the change introduced by the blame commit specifically. Outside of that (especially if reverting the commit of top on master yields the same VRAM exhaustion), it looks a bit weird that a ddraw game hits that, it may happen that there are issues in ddraw or elsewhere which lead to excessive VRAM usage which can be fixed. -- 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=53737 --- Comment #10 from Prajna Sariputra <putr4.s(a)gmail.com> --- Created attachment 73230 --> https://bugs.winehq.org/attachment.cgi?id=73230 Terminal output + backtrace (master minus dfd5f109fb4) The line below does indeed still exist in this log:
010c:err:d3d:wined3d_resource_allocate_sysmem Failed to allocate system memory.
-- 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=53737 --- Comment #11 from Paul Gofman <pgofman(a)codeweavers.com> --- So I am not sure that attribution of the regression to commit dfd5f109fb4ebad859bf3ce3960b3b2b2ad1341d is fully correct (although of course it increased VM usage a bit). If possible, it would be interesting to further bisect the regression after that blamed commit by doing the bisect starting from the next after dfd5f109fb4ebad859bf3ce3960b3b2b2ad1341d and applying the revert on each step. It can be done by putting the revert as a patch and doing 'git apply revert.patch' at each step, then 'git reset --hard' after build. Yet I think the most interesting is why it is so close to VM exhaustion even before dfd5f109fb4ebad859bf3ce3960b3b2b2ad1341d, the major issue (if there is indeed a specific one and not just borderline VRAM usage by the game plus usual pulseaudio etc. overhead) is probably elsewhere. That needs some debugging. -- 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=53737 --- Comment #12 from Prajna Sariputra <putr4.s(a)gmail.com> --- The bisection excluding dfd5f109 and reverting said commit before every build reports the first bad commit as deaf0891b096628cf99e58834c39a45a6c99c54c (2 May, first appearing in release 7.10), which is:
ntdll: Improve block size rounding compatibility.
This also increase the default heap size to 2MiB (32bit) / 4MiB (64bit), for the tests to pass.
Unfortunately that commit does not revert cleanly on top of master, but doing so on 7.10 does make the game work in addition to also reverting dfd5f109. So, here are the additional test results: 7.9 minus dfd5f109: ok 7.10 minus dfd5f109: fail 7.10 minus dfd5f109 and deaf0891: ok The fail case there also has `0100:err:d3d:wined3d_resource_allocate_sysmem Failed to allocate system memory.` in the terminal output. I can upload the whole output+backtrace if needed, although I'm guessing it won't be any more helpful given that it looks like deaf0891 is just like dfd5f109 in that they happen to push the memory usage just past the limit. -- 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=53737 joaopa <jeremielapuree(a)yahoo.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree(a)yahoo.fr --- Comment #13 from joaopa <jeremielapuree(a)yahoo.fr> --- with wine-8.12 no crash but messy graphics and the line is here
0170:err:d3d:wined3d_resource_allocate_sysmem Failed to allocate system memory.
-- 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.
http://bugs.winehq.org/show_bug.cgi?id=53737 Gijs Vermeulen <gijsvrm(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #14 from Gijs Vermeulen <gijsvrm(a)gmail.com> --- Game does not crash, but graphics look a bit weird. This seems in line with Comment #13, although I do not get any allocation failure messages. Let's call this one FIXED and a new bug can be opened for the graphical issues. Please reopen if you can still reproduce. -- 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)
-
WineHQ Bugzilla