[Bug 55903] New: Falcon BMS 4.37u3: game randomly fails to load 3D models
https://bugs.winehq.org/show_bug.cgi?id=55903 Bug ID: 55903 Summary: Falcon BMS 4.37u3: game randomly fails to load 3D models Product: Wine Version: 8.17 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: xeno(a)x-s.com.pl Distribution: --- Created attachment 75439 --> https://bugs.winehq.org/attachment.cgi?id=75439 Screenshots of the problem On random runs no 3D models are visible in game, both in TacRef (game encyclopedia) and in 3D world (screenshots attached). If it happens there are messages in the game debug logs about skipping load LODs: Log entry: 400 Skipping LOD load, lodIdx is negative: -1261039100 This state is permanent across the run, ie if models aren't loaded from the very beginning, they won't, until game is closed. Launching it once again, may load 3D models properly (chance is about 30%). Game is installed as follows: 1. Created new 64-bit wine prefix, set as Windows 10(default). 2 Created separate drive (here E:), pointing to dir in my home dir where all games are installed. 3. Installed DXVK and external libraries: *d3dx11_43, *d3dcompiler_43 installed via winetricks. 4. Installed Original Falcon 4 (needed by BMS for legal reasons) 5. Installed Falcon BMS 4.37 update 3 (using full installer, direct to latest version, no updates on older release) Game was run with --mono switch to get debug logs. System specs; Hardware: CPU: Ryzen 5 5600X; M/B: MSI B550-A PRO; RAM: 16GB DDR4 Patriot Viper 3733MHz CL17; GPU: Saphire Pulse RX5700XT BE OS: Fedora 38 x86_64; kernel 6.5.9-200; libdrm-2.4.117; mesa-23.1.9; wine-8.19; dxvk-2.3 Wine is installed from Fedora rpms, issue is present both in X11 and Wayland session. Using wine build-in D3D11 wrapper instead of DXVK makes no difference. Also it doesn't matter if game launcher (needs extra .Net 4.6.2) is used or game executable is launched directly from command prompt This issue is not present in previous versions of Wine, last known working is 8.14. 8.15/16 weren't tested as there are no Fedora rpms with those releases. If needed copy of Falcon4 can be provided, BMS itself can be downloaded for free from project home page: https://www.falcon-bms.com/downloads/ -- 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=55903 --- Comment #1 from Stan aka Xeno <xeno(a)x-s.com.pl> --- I've talked with one of the app devs to get some hints what app is doing in this place. To quote what he said: [...] Essentially, its a pointer trick. Lodidx comes from the object memory address - the first object in the array. its pointer arithmetics, something which is not recommended, but works. const int lodIdx = static_cast<int>(this - TheObjectLODs); Theobjectlods is an array of objects. So we take our address and subtract from the array. This should give us our index. For example, in a very simplified way, if our address is 10 and the array starts at 8, we are index 2 (because 0 is not valid). Maybe wine changed pointer arithmetic behavior for security reasons [...] -- 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=55903 Fabian Maurer <dark.shadow4(a)web.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dark.shadow4(a)web.de --- Comment #2 from Fabian Maurer <dark.shadow4(a)web.de> --- Does it work reliably with wine-8.14? If so, could you do a regression test to see what broke it?
Essentially, its a pointer trick. Lodidx comes from the object memory address - the first object in the array. its pointer arithmetics, something which is not recommended, but works.
const int lodIdx = static_cast<int>(this - TheObjectLODs);
I don't quite understand it yet. For now it looks more like undefined behavior to me. Seems like "TheObjectLODs" is bigger than "this", thus you get some massive negative value. If it the same object from one single(!) allocation I don't see how this could go wrong. A bigger code snippet could help cast light on this, but I doubt the'll be willing to provide that. -- 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=55903 --- Comment #3 from Stan aka Xeno <xeno(a)x-s.com.pl> --- Hi, thanks for an answer, I think it's fairly sure 8.14 works. For several days, I've been trying various releases from 7.22 (reported working by other use,, Wine 8.0, 8.6, 8.11 and 8.14. For each ther was about 30-50 runs of BMS without this issue occuring. 8.17 failed on the first run. What's even more puzzling, this problem appears to be a bit random. THere might be tw, three runs with game working fine, then next ten problem may appear. I'll try to do bisect, but it might take a while, as I have to learn how to build Wine Fedora way. I'll also try to ask BMS devs some more questions, 'tho it also takes time as BMS is a volunteer project and guys are busy with cooking next update. -- 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=55903 --- Comment #4 from Stan aka Xeno <xeno(a)x-s.com.pl> --- I can confirm it's 8.17 to blame. I've build rough Wine 8.15, .16 and .17 packages from Fedora specs with disabled staging patches for simplicity. Wine, up to 8.16 behaves correctly, 8.17 locally build exactly the same way as previous releases fails pretty reliably. A question do you know, or how do I find which commits mark 8.16 and 8.17 release so I can run git bisect? -- 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=55903 --- Comment #5 from Stan aka Xeno <xeno(a)x-s.com.pl> --- So I was able to bisect 8.17 release. From what git says it's [a81c53504ae32715e6e91bd020fdebd5bef20d48] ntdll: Release the low address space reservation for 64-bit apps. commit, that causes the issue. Which kinda makes sense. Author: Alexandre Julliard <julliard(a)winehq.org> AuthorDate: Thu Sep 28 16:30:32 2023 +0200 Commit: Alexandre Julliard <julliard(a)winehq.org> CommitDate: Thu Sep 28 22:35:41 2023 +0200 ntdll: Release the low address space reservation for 64-bit apps. -- 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=55903 --- Comment #6 from Stan aka Xeno <xeno(a)x-s.com.pl> --- Log from git bisect: git bisect start # status: waiting for both good and bad commits # good: [cf5e073d14925d3cdd489a869e3c2c5317b1ff38] Release 8.16. git bisect good cf5e073d14925d3cdd489a869e3c2c5317b1ff38 # status: waiting for bad commit, 1 good commit known # bad: [3db7506221e44e8091887d7eb42fe1666d422166] Release 8.17. git bisect bad 3db7506221e44e8091887d7eb42fe1666d422166 # good: [6ce99d16a6445705a7a0cfc6f8835930b8c25292] d3d10/effect: Add signed integer compare instructions for expressions. git bisect good 6ce99d16a6445705a7a0cfc6f8835930b8c25292 # good: [fb0c4ec5a32791ce43eecffcafc4478da26c7d6e] wined3d: Make wined3d_stateblock_state_{init,cleanup}() static. git bisect good fb0c4ec5a32791ce43eecffcafc4478da26c7d6e # bad: [25f3ba3e069d38ec2bd5f66980f3780bbf1abe94] include: Correct conflicting definition of PSECURITY_DESCRIPTOR. git bisect bad 25f3ba3e069d38ec2bd5f66980f3780bbf1abe94 # good: [e0a5f3564972b0a51e3c14a8fcf1e8f0dcdd0c73] winewayland.drv: Remove wayland_surface destruction double locking. git bisect good e0a5f3564972b0a51e3c14a8fcf1e8f0dcdd0c73 # good: [902133b0086307b5e2b33818dd0b22a95568206c] winegstreamer: Correct output available types attrs in AAC decoder for channel count > 2. git bisect good 902133b0086307b5e2b33818dd0b22a95568206c # bad: [9b60b671da82123590253472318d95547d8d138d] ntdll: Don't release the low address space reservation on wow64. git bisect bad 9b60b671da82123590253472318d95547d8d138d # good: [416a273241e6eb7a8d15380387fef00e159b7277] winegstreamer: Also return output with 2 channels for multichannel inputs from AAC decoder. git bisect good 416a273241e6eb7a8d15380387fef00e159b7277 # bad: [a81c53504ae32715e6e91bd020fdebd5bef20d48] ntdll: Release the low address space reservation for 64-bit apps. git bisect bad a81c53504ae32715e6e91bd020fdebd5bef20d48 # first bad commit: [a81c53504ae32715e6e91bd020fdebd5bef20d48] ntdll: Release the low address space reservation for 64-bit apps. -- 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=55903 Stan aka Xeno <xeno(a)x-s.com.pl> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |julliard(a)winehq.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=55903 Stan aka Xeno <xeno(a)x-s.com.pl> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |ntdll -- 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=55903 Matheus Ribeiro <mfribeiro(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mfribeiro(a)gmail.com --- Comment #7 from Matheus Ribeiro <mfribeiro(a)gmail.com> --- (In reply to Fabian Maurer from comment #2)
Does it work reliably with wine-8.14? If so, could you do a regression test to see what broke it?
Essentially, its a pointer trick. Lodidx comes from the object memory address - the first object in the array. its pointer arithmetics, something which is not recommended, but works.
const int lodIdx = static_cast<int>(this - TheObjectLODs);
I don't quite understand it yet. For now it looks more like undefined behavior to me. Seems like "TheObjectLODs" is bigger than "this", thus you get some massive negative value. If it the same object from one single(!) allocation I don't see how this could go wrong. A bigger code snippet could help cast light on this, but I doubt the'll be willing to provide that.
Hi Fabian, BMS dev here. TheObjectLODs is a global array, populated during application startup. All ObjectLOD used are in this array (and first position is invalid). So, `this`, is one of those objects. When we do `this - ObjectLOD` we are essentially computing the index. Notice that pointer subtraction is well defined behavior (contrary to pointer addition, which makes no sense). And the number of LODs is a few tens of thousands, so it is not an integer overflow. The offending code is here: ``` void ObjectLOD::Load() { PROFILE( ObjectLOD_Load ); const int lodIdx = static_cast<int>(this - TheObjectLODs); g_nLoadingLOD = lodIdx; if (lodIdx < 0) { NL_MONOPRINT(NL_ERROR, "Skipping LOD load, lodIdx is negative: %d", lodIdx); return; } ``` Not much to show from this, but let me know if you need more information. -- 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=55903 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1| |a81c53504ae32715e6e91bd020f | |debd5bef20d48 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=55903 Zeb Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12(a)gmail.com --- Comment #8 from Zeb Figura <z.figura12(a)gmail.com> --- Regressions from a81c53504a usually occur because a 64-bit pointer is truncated to the bottom 32 bits. It's not obvious to me why that'd happen here; probably the truncation is happening earlier. I guess "TheObjectLODs" is probably .data or .rdata? Can we get a +loaddll log? Is "This" some garbage, or possibly NULL? -- 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=55903 --- Comment #9 from Fabian Maurer <dark.shadow4(a)web.de> --- Thanks for the insights, although I currently don't see anything wrong with that. Since "this" is the c++ this pointer, I don't think that is NULL or invalid. TheObjectLODs should be an nonchanging ObjectLOD pointer, so this seems valid as well. Not sure if that is an option, but you could log the addresses of both "this" and "TheObjectLODs" before trying that subtraction, that should show if there is any funny business going on. I mean, one of them has to be off, but I currently can't see how. Unless maybe there's an object that is accidentally copied, then "this" is suddenly completely out of bounds. I assume that "TheObjectLODs" is not getting relocated either? Sorry, it's kinda hard for me without seeing the entire thing. -- 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=55903 --- Comment #10 from Stan aka Xeno <xeno(a)x-s.com.pl> --- Is there any way to run it trough some debugger and save the trace to see what's really going on there? What also makes me puzzled it's not-100% reproducible. There's about 20-30% chance it'll work for whole BMS session. So it's not that something is totally wrong, it just usually hits a condition where things got messed up. -- 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=55903 --- Comment #11 from Fabian Maurer <dark.shadow4(a)web.de> --- Wine does have debugging functionality, but I don't see how it could be useful here. But since Zeb suggested a "+loaddll" log, why not try that and see what they say? -- 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=55903 --- Comment #12 from Stan aka Xeno <xeno(a)x-s.com.pl> --- Created attachment 75490 --> https://bugs.winehq.org/attachment.cgi?id=75490 +loaddll log from running good session - models loaded and visible -- 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=55903 --- Comment #13 from Stan aka Xeno <xeno(a)x-s.com.pl> --- Created attachment 75491 --> https://bugs.winehq.org/attachment.cgi?id=75491 loaddll log from running bad session - models not loaded As requested, I've uploaded logs of running BMS with WINEDEBUG=+loaddll parameter from both good (models visible) and bad (models invisible) sessions under the same build of Wine (8.17 from official Fedora repo) -- 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=55903 --- Comment #14 from Stan aka Xeno <xeno(a)x-s.com.pl> --- I've just tried wne-8.21, bug is still present. -- 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=55903 Fabian Maurer <dark.shadow4(a)web.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #15 from Fabian Maurer <dark.shadow4(a)web.de> --- Marking as dupe of 55833 to collect similar issues. Feel free to reopen in case this is a different problem. *** This bug has been marked as a duplicate of bug 55833 *** -- 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=55903 --- Comment #16 from Fabian Maurer <dark.shadow4(a)web.de> --- That said, I'm still curious what exactly goes wrong here. Like, where does the truncation happen?
Not sure if that is an option, but you could log the addresses of both "this" and "TheObjectLODs" before trying that subtraction, that should show if there is any funny business going on. I mean, one of them has to be off, but I currently can't see how.
What about that idea, is that doable? -- 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=55903 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #17 from Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> --- Closing duplicate. -- 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=55903 --- Comment #18 from Fabian Maurer <dark.shadow4(a)web.de> --- Is this fixed by f03c3a167c2e4abe92b1e1bf2ea5f7c31a07fc3b ? -- 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=55903 --- Comment #19 from Stan aka Xeno <xeno(a)x-s.com.pl> --- Unfortunately wine 9.0-rc1 didn't solved this issue. -- 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=55903 --- Comment #20 from Stan aka Xeno <xeno(a)x-s.com.pl> --- However if I patch dlls/ntdll/unix/virtual.c with patch from https://bugs.winehq.org/attachment.cgi?id=75619&action=diff issue didn't appear in 10 consecutive runs, which is very unlikely to happen with clean 9.0-rc1 -- 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=55903 Bernhard Übelacker <bernhardu(a)mailbox.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bernhardu(a)mailbox.org --- Comment #21 from Bernhard Übelacker <bernhardu(a)mailbox.org> --- Should this bug also get "unduplicated"? And should it get reopened because f03c3a167 did not fix it, and due to comment 19 it still happens with wine 9.0-rc1? -- 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=55903 Fabian Maurer <dark.shadow4(a)web.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|DUPLICATE |--- Status|CLOSED |REOPENED Ever confirmed|0 |1 --- Comment #22 from Fabian Maurer <dark.shadow4(a)web.de> --- Yeah, I guess you're right. -- 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=55903 --- Comment #23 from Fabian Maurer <dark.shadow4(a)web.de> --- Does https://gitlab.winehq.org/wine/wine/-/commit/7a7b82880a73e654933b7866e79f3e9... fix this? -- 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=55903 --- Comment #24 from Stan aka Xeno <xeno(a)x-s.com.pl> --- Haven't tested it yet, but it's quite likely yes, because similar patches posted by tuxway+wine(a)posteo.de in https://bugs.winehq.org/show_bug.cgi?id=55833 did solve the problem. I'll try to build new package and test it tommorow. -- 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=55903 --- Comment #25 from Stan aka Xeno <xeno(a)x-s.com.pl> --- Yep Wine-9.0rc2 fixes the problem. Thanks all involved. -- 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=55903 Stan aka Xeno <xeno(a)x-s.com.pl> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution|--- |FIXED --- Comment #26 from Stan aka Xeno <xeno(a)x-s.com.pl> --- Fixed in Wine 9.0-rc2 -- 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=55903 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #27 from Alexandre Julliard <julliard(a)winehq.org> --- Closing bugs fixed in 9.0-rc3. -- 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