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@winehq.org Reporter: rawfox@freenet.de CC: leslie_alistair@hotmail.com, z.figura12@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.
https://bugs.winehq.org/show_bug.cgi?id=51720
rawfox rawfox@freenet.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|ntdll-ForceBotoomUpAlloc - |ntdll-ForceBottomUpAlloc - |StarCitizen crashing on |StarCitizen crashing on |start |start CC| |rawfox@freenet.de
https://bugs.winehq.org/show_bug.cgi?id=51720
--- Comment #1 from rawfox rawfox@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
https://bugs.winehq.org/show_bug.cgi?id=51720
--- Comment #2 from rawfox rawfox@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.
https://bugs.winehq.org/show_bug.cgi?id=51720
--- Comment #3 from rawfox rawfox@freenet.de --- Both crashes happen under the very same build.
https://bugs.winehq.org/show_bug.cgi?id=51720
Paul Gofman pgofman@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |pgofman@codeweavers.com
--- Comment #4 from Paul Gofman pgofman@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.
https://bugs.winehq.org/show_bug.cgi?id=51720
--- Comment #5 from rawfox rawfox@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
https://bugs.winehq.org/show_bug.cgi?id=51720
--- Comment #6 from Paul Gofman pgofman@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).
https://bugs.winehq.org/show_bug.cgi?id=51720
--- Comment #7 from rawfox rawfox@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.
https://bugs.winehq.org/show_bug.cgi?id=51720
--- Comment #8 from Paul Gofman pgofman@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.
https://bugs.winehq.org/show_bug.cgi?id=51720
--- Comment #9 from rawfox rawfox@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.
https://bugs.winehq.org/show_bug.cgi?id=51720
--- Comment #10 from Paul Gofman pgofman@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').
https://bugs.winehq.org/show_bug.cgi?id=51720
--- Comment #10 from Paul Gofman pgofman@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@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').
https://bugs.winehq.org/show_bug.cgi?id=51720
--- Comment #12 from rawfox rawfox@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 ^^
https://bugs.winehq.org/show_bug.cgi?id=51720
--- Comment #13 from rawfox rawfox@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^^
https://bugs.winehq.org/show_bug.cgi?id=51720
--- Comment #14 from rawfox rawfox@freenet.de --- wine-6.19 (Staging)^^ 8.19 still upcoming xD
https://bugs.winehq.org/show_bug.cgi?id=51720
--- Comment #15 from rawfox rawfox@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.
https://bugs.winehq.org/show_bug.cgi?id=51720
--- Comment #16 from Paul Gofman pgofman@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.
https://bugs.winehq.org/show_bug.cgi?id=51720
--- Comment #17 from Paul Gofman pgofman@codeweavers.com --- This is supposed to be fixed with upstream commit 1722615b06cba2f04fcd0ca69bbc33d963fb143f (I mean the issue specific to this report stated in subject).
https://bugs.winehq.org/show_bug.cgi?id=51720
--- Comment #18 from rawfox rawfox@freenet.de --- Confirming, its fixed. Thanks a ton, you made a lot of penguins happy. <3
https://bugs.winehq.org/show_bug.cgi?id=51720
rawfox rawfox@freenet.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED
--- Comment #19 from rawfox rawfox@freenet.de --- marked as fixed
https://bugs.winehq.org/show_bug.cgi?id=51720
rawfox rawfox@freenet.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #20 from rawfox rawfox@freenet.de --- closed
-
WineHQ Bugzilla