[Bug 51720] New: ntdll-ForceBotoomUpAlloc - StarCitizen crashing on start
https://bugs.winehq.org/show_bug.cgi?id=51720 Bug ID: 51720 Summary: ntdll-ForceBotoomUpAlloc - StarCitizen crashing on start Product: Wine-staging Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: rawfox(a)freenet.de CC: leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com Distribution: --- SC works on wine-vanilla. It used to work on wine-staging better, due to the benefits of some patches. Since a couple weeks, SC on wine-staging crashed when pressing play in the launcher. Netho from #LUG found the staging patch ntdll-ForceBottomUpAlloc the source of the crashes. Removing that patch and its dependencies made the game load and work again. --all -W ntdll-ForceBottomUpAlloc -W ntdll-WRITECOPY -W ntdll-Builtin_Prot Problem is, the game performance is reduced by 50%, when removing that patch. Removing all ntdll* patches from the staging patchset made the game work fine again, no issues there, but we miss all the tweaks for ntdll from the staging patches. No idea, whats wrong with ntdll-ForceBottomUpAlloc . Netho futher found /0003-ntdll-Force-virtual-memory-allocation-order.patch is the patch that causes the 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=51720 rawfox <rawfox(a)freenet.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|ntdll-ForceBotoomUpAlloc - |ntdll-ForceBottomUpAlloc - |StarCitizen crashing on |StarCitizen crashing on |start |start CC| |rawfox(a)freenet.de -- 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=51720 --- Comment #1 from rawfox <rawfox(a)freenet.de> --- Created attachment 70645 --> https://bugs.winehq.org/attachment.cgi?id=70645 crash typ 1 device error crash typ 1 complains about a missing device -- 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=51720 --- Comment #2 from rawfox <rawfox(a)freenet.de> --- Created attachment 70646 --> https://bugs.winehq.org/attachment.cgi?id=70646 crash typ 2 red error in launcher crash typ 2 is, when pressing launch and confirming the nerf requester, it gives a instant red error msg by the launcher. -- 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=51720 --- Comment #3 from rawfox <rawfox(a)freenet.de> --- Both crashes happen under the very same build. -- 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=51720 Paul Gofman <pgofman(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |pgofman(a)codeweavers.com --- Comment #4 from Paul Gofman <pgofman(a)codeweavers.com> --- Can you please attach the full uncut log with failure with WINEDEBUG=+pid,+timestamp,+seh,+loaddll,+virtual,+dialog,+msgbox? The log may grow rather big but they are compressed very well. -- 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=51720 --- Comment #5 from rawfox <rawfox(a)freenet.de> --- Created attachment 70659 --> https://bugs.winehq.org/attachment.cgi?id=70659 WINEDEBUG=+pid,+timestamp,+seh,+loaddll,+virtual,+dialog,+msgbox started SC with WINEDEBUG=+pid,+timestamp,+seh,+loaddll,+virtual,+dialog,+msgbox -- 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=51720 --- Comment #6 from Paul Gofman <pgofman(a)codeweavers.com> --- Created attachment 70660 --> https://bugs.winehq.org/attachment.cgi?id=70660 For test only Just to make sure I understand correctly what's going on (pretty much think so looking at the log), could you please check if the attach patch changes anything (that's not a correct fix, a correct fix will require some testing and consideration). -- 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=51720 --- Comment #7 from rawfox <rawfox(a)freenet.de> --- Yes, that patch made the game load again. Awesome <3 There is still a performance problem. If you need futher logs, let me know. -- 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=51720 --- Comment #8 from Paul Gofman <pgofman(a)codeweavers.com> --- (In reply to rawfox from comment #7)
Yes, that patch made the game load again. Awesome <3 There is still a performance problem. If you need futher logs, let me know.
I am not sure I understand what exactly is the performance problem. Is that problem with the concerned patchset or without? If without, I am not sure how do you guessing that it is in play since the game is crashing with the patchset? And with a test patch it works but performance problem is still there? If yes, it is probably not related to the patcset. And in any case deserves the separate report with proper description. -- 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=51720 --- Comment #9 from rawfox <rawfox(a)freenet.de> --- Performance seen by FPS in game. With all staging patches for ntdll* its crashing. Removing ntdll-ForceBottomUpAlloc and its deps from staging patches, its loading but FPS is half as good as .. Removing all ntdll* patches from staging game is loading and performs normal (double FPS) but applying your patch made the game work but the FPS is not as good, as if we remove all ntdll* patches from Staging patchset. It feels like this Problem exists since here: https://bugs.winehq.org/show_bug.cgi?id=50992 The function is just stubbed out, but .. hung soon later. Thats all old the while, but i remember me thinking "stubbin it is not enuff" because the providing windows API for QueryTraceA is not in wine implemented, but QueryTraceW is ... from another API. -- 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=51720 --- Comment #10 from Paul Gofman <pgofman(a)codeweavers.com> --- So, if I understand correctly, (In reply to rawfox from comment #9)
Performance seen by FPS in game.
With all staging patches for ntdll* its crashing.
Removing ntdll-ForceBottomUpAlloc and its deps from staging patches, its loading but FPS is half as good as ..
Removing all ntdll* patches from staging game is loading and performs normal (double FPS)
So this suggests that the issue might be related to one of ntdll- Staging patches, but clearly not ntdll-ForceBottomUpAlloc, as removing it (with some other patches) leaves performace bad, right? I suggest to stop messing up this particular bug and open a new one for this issue. For the sake of that new bug it would be great if it was bisected which exactly ntdll patch is causing the FPS drop (for bisect steps which have ntdll-ForceBottomUpAlloc it is possible to apply the diff from here to avoid the crash and then 'git reset --hard' to remove that diff before 'git bisect good' or 'git bisect bad'). -- 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=51720 --- Comment #10 from Paul Gofman <pgofman(a)codeweavers.com> --- So, if I understand correctly, (In reply to rawfox from comment #9)
Performance seen by FPS in game.
With all staging patches for ntdll* its crashing.
Removing ntdll-ForceBottomUpAlloc and its deps from staging patches, its loading but FPS is half as good as ..
Removing all ntdll* patches from staging game is loading and performs normal (double FPS)
So this suggests that the issue might be related to one of ntdll- Staging patches, but clearly not ntdll-ForceBottomUpAlloc, as removing it (with some other patches) leaves performace bad, right? I suggest to stop messing up this particular bug and open a new one for this issue. For the sake of that new bug it would be great if it was bisected which exactly ntdll patch is causing the FPS drop (for bisect steps which have ntdll-ForceBottomUpAlloc it is possible to apply the diff from here to avoid the crash and then 'git reset --hard' to remove that diff before 'git bisect good' or 'git bisect bad'). --- Comment #11 from Paul Gofman <pgofman(a)codeweavers.com> --- So, if I understand correctly, (In reply to rawfox from comment #9)
Performance seen by FPS in game.
With all staging patches for ntdll* its crashing.
Removing ntdll-ForceBottomUpAlloc and its deps from staging patches, its loading but FPS is half as good as ..
Removing all ntdll* patches from staging game is loading and performs normal (double FPS)
So this suggests that the issue might be related to one of ntdll- Staging patches, but clearly not ntdll-ForceBottomUpAlloc, as removing it (with some other patches) leaves performace bad, right? I suggest to stop messing up this particular bug and open a new one for this issue. For the sake of that new bug it would be great if it was bisected which exactly ntdll patch is causing the FPS drop (for bisect steps which have ntdll-ForceBottomUpAlloc it is possible to apply the diff from here to avoid the crash and then 'git reset --hard' to remove that diff before 'git bisect good' or 'git bisect bad'). -- 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=51720 --- Comment #12 from rawfox <rawfox(a)freenet.de> --- Yes, you understood that all right. Okay, we gonna hunt the patch down, wich is causing the performance issue and ill drop a new bugreport for that, once we found it. Happy, this loading thing is solved so far, even if implementation may need futher time, but for now, its starting again, thanks a ton ^^ -- 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=51720 --- Comment #13 from rawfox <rawfox(a)freenet.de> --- After a lot more tests, i still have no result :/ The game still has the same behavior with wine-6.19 (Staging). Excluding all ntdll_* patches from a build makes the game perform 30%-50% better, then including them all and applying the testpatch. As you seem to understand the issue, because your testpatch nailed it oneshot, i would like to give the ball back to you ppl. I could not find a pattern within the ntdll_* patches, some are depended by others, some are disabled, some seem to be w.i.p., /shrug .. im a nurse, reporting symptoms, the medicine must come from you :p With ntdll_* patches in staging, it needs a patch and works obviously not optimal. Without them it does not need a patch and works a lot better. Removing single ntdll_* patches aint made a difference, i made a ton of builds. As you mentioned, the patch is a ruff fix and its implementation will need some time, i just wanted to report this for wine-8.19 (Staging). Cheers and happy weekend^^ -- 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=51720 --- Comment #14 from rawfox <rawfox(a)freenet.de> --- wine-6.19 (Staging)^^ 8.19 still upcoming xD -- 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=51720 --- Comment #15 from rawfox <rawfox(a)freenet.de> --- Once this initial crash bug is fixed in wine-staging, ill create a new bugreport about the performance problem with the ntdll-* patches. -- 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=51720 --- Comment #16 from Paul Gofman <pgofman(a)codeweavers.com> --- Any reason to put that into dependency? I honestly don't see how that is related or dependent. And there is a chance the correct fix might be needed upstream, not in Wine Staging, even though the problem in Star Citizen is triggered by this patch. What happens here is that the first 2GB runs out of address space (in 64 bit process), and that is the only space which is currently used for threads' TEBs. So no TEB can be created and thread creation fails. While "bottom up alloc" patchset makes it more likely, I suspect that the issue might be more about that we allocate 0x200000 for each TEB and require all of that to fit in the low 2GB. That needs more investigation though. -- 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=51720 --- Comment #17 from Paul Gofman <pgofman(a)codeweavers.com> --- This is supposed to be fixed with upstream commit 1722615b06cba2f04fcd0ca69bbc33d963fb143f (I mean the issue specific to this report stated in subject). -- 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=51720 --- Comment #18 from rawfox <rawfox(a)freenet.de> --- Confirming, its fixed. Thanks a ton, you made a lot of penguins happy. <3 -- 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=51720 rawfox <rawfox(a)freenet.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #19 from rawfox <rawfox(a)freenet.de> --- marked as 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=51720 rawfox <rawfox(a)freenet.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #20 from rawfox <rawfox(a)freenet.de> --- closed -- 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