https://bugs.winehq.org/show_bug.cgi?id=49633
Bug ID: 49633 Summary: StarCitizen launcher crashes on start with a winmm error Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: msvcrt Assignee: wine-bugs@winehq.org Reporter: rawfox@freenet.de Distribution: ---
Hello again^^
Commit f02193738c88bea8fefb3f8d2e79c5e9941f6b5a is crashing the StarCitizen launcher at start.
https://github.com/wine-mirror/wine/commit/f02193738c88bea8fefb3f8d2e79c5e99...
Reverting that commit let the launcher start correctly.
git revert f02193738c88bea8fefb3f8d2e79c5e9941f6b5a git rebase -i
Thats what i did to revert the commit, but as the commit itself looks fine, there may be coming invalid data to it. MSVCRT_size_t ?!
https://bugs.winehq.org/show_bug.cgi?id=49633
rawfox rawfox@freenet.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |rawfox@freenet.de
https://bugs.winehq.org/show_bug.cgi?id=49633
rawfox rawfox@freenet.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|rawfox@freenet.de |
https://bugs.winehq.org/show_bug.cgi?id=49633
Piotr Caban piotr.caban@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1| |f02193738c88bea8fefb3f8d2e7 | |9c5e9941f6b5a CC| |piotr.caban@gmail.com Keywords| |regression
https://bugs.winehq.org/show_bug.cgi?id=49633
--- Comment #1 from Piotr Caban piotr.caban@gmail.com --- It looks like there's some kind of race in the launcher. It's possible to reproduce the crash with native vcruntime140/ucrtbase (sometimes). Also it doesn't always crash when builtin dlls are used.
https://bugs.winehq.org/show_bug.cgi?id=49633
Paul Gofman pgofman@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |pgofman@codeweavers.com
--- Comment #2 from Paul Gofman pgofman@codeweavers.com --- (In reply to Piotr Caban from comment #1)
It looks like there's some kind of race in the launcher. It's possible to reproduce the crash with native vcruntime140/ucrtbase (sometimes). Also it doesn't always crash when builtin dlls are used.
Maybe something in game depends on memory being "properly" self overwritten by memcpy within the overlapping memory ranges and not correctly moved?
https://bugs.winehq.org/show_bug.cgi?id=49633
--- Comment #3 from Piotr Caban piotr.caban@gmail.com --- (In reply to Paul Gofman from comment #2)
Maybe something in game depends on memory being "properly" self overwritten by memcpy within the overlapping memory ranges and not correctly moved?
No (before this patch we were already moving the memory in memcpy, also native dlls are working as expected in this regard and it's still possible to reproduce the crash, we also have tests in msvcrt that this is the expected behavior, I didn't test ucrtbase though).
https://bugs.winehq.org/show_bug.cgi?id=49633
--- Comment #4 from rawfox rawfox@freenet.de --- It gets a little odd here because this bug does not happen when wine is build on older build environments.
We have tested this with creating a Lutris runner for StarCitizen with the current 5.16 and its not happening there a single time. The build environment on the podman containers is Ubuntu18.
Just local builds on more recent build environments dropping the winmm error and let the games launcher crash. I am locally on Fedora32.
So this may neither be a launcher or a wine issue but something with the build system versions ?!
Im using gcc (GCC) 10.2.1 20200723 (Red Hat 10.2.1-1).
/shrug
https://bugs.winehq.org/show_bug.cgi?id=49633
--- Comment #5 from rawfox rawfox@freenet.de --- This issue seems to be bound to hardware accelleration used by the launcher. When we pass Arguments to it, then there is no winmm error anymore.
Passed arguments are
`--use-gl=osmesa` or `--use-gl=--override-use-software-gl-for-tests`
to prevent the winmm error.
So this bug has a workaround now, but why doesnt it happen on Windows ? And why doesnt it it happen on wine, built on lower build systems ?!
Thanks go to gort818, who figured this out \m/
https://bugs.winehq.org/show_bug.cgi?id=49633
--- Comment #6 from Paul Gofman pgofman@codeweavers.com --- I tried to debug the issue but could not reproduce it. I installed the current launcher in a clean prefix with Wine git:
v1.4.6. sha1sum RSI Launcher.exe: 7d98406b2dad67ac3c3490f6e96ffd15e7793d7b RSI Launcher.exe
The installation crashed on the way but still completed after closing the crash dialog.
The launcher started for me without crashes, it had black screen though. That was due to it tries to render to the other's process window. I worked that around by using the following command line arguments for RSI Launch:
--disable-features=SpareRendererForSitePerProcess --disable-gpu-compositing
Then, the launcher displayed correctly, and I could attempt login which gave me an error "Your account doesn't have a game package, ...", which is true as I didn't purchase one.
Is the issue still reproducible? If yes, could you please provide full details on how you install and start the launcher, and any workarounds / quirks which are used on the waY?
https://bugs.winehq.org/show_bug.cgi?id=49633
--- Comment #7 from rawfox rawfox@freenet.de --- Thank you for the efforts!
The history has changed it a little. While this report gave us the winmm error, the road of wine development changed the bahavior of the launcher.
We found the issue is about 3d accelleration, wich would fit your observation about the renderer. Giving the argument --use-gl=osmesa to the launcher, could supress the error and the launcher came up fine.
Now it changed again, the launcher drops a dcomp error, that seems to be related to dxgi anyhow. This is the error: Unhandled exception: unimplemented function dcomp.dll.DCompositionCreateDevice called in 64-bit code (0x000000007b011e1e).
DCompositionCreateDevice is missing in wine for now, as dcomp is pretty empty. Ive tried to make an override with winecfg, but only in the StarCitizen prefix the winecfg dropped me a core dump. On a default prefix the very same winecfg works well.
The dcomp error drops 3 times and can be ignored / clicked away, the launcher comes up fine. The argument --disable-gpu-compositing supresses the error and the launcher comes up clean and fine as well.
let see, what we get when wine-6 releases, im on wine-6.0-rc3 with this ..
https://bugs.winehq.org/show_bug.cgi?id=49633
--- Comment #8 from rawfox rawfox@freenet.de --- I should have mentioned, the inital report here was with launcher version v1.4.5, the update to 1.4.6 was just about 3 weeks ago or something, that was the reason that the thing changed its behavior.
https://bugs.winehq.org/show_bug.cgi?id=49633
--- Comment #9 from Piotr Caban piotr.caban@gmail.com --- I'm not sure what's the status of this bug (probably behavior of the launcher has changed). Problem identified by regression test should be fixed by 38c490496000c5852f14e9c022868c5107d9ff03.
https://bugs.winehq.org/show_bug.cgi?id=49633
--- Comment #10 from rawfox rawfox@freenet.de --- Since yesterday, we are at launcher 1.4.10 and still need to pass `--use-gl=osmesa` or we get a empty white launcher window.
This w/a is fine for now.
https://bugs.winehq.org/show_bug.cgi?id=49633
Piotr Caban piotr.caban@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords|regression | Regression SHA1|f02193738c88bea8fefb3f8d2e7 | |9c5e9941f6b5a |
https://bugs.winehq.org/show_bug.cgi?id=49633
Piotr Caban piotr.caban@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|msvcrt |-unknown
https://bugs.winehq.org/show_bug.cgi?id=49633
Ken Sharp imwellcushtymelike@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|unspecified |5.14
--- Comment #11 from Ken Sharp imwellcushtymelike@gmail.com --- Please retry in Wine 7.9 (or later).
https://bugs.winehq.org/show_bug.cgi?id=49633
rawfox rawfox@freenet.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
--- Comment #12 from rawfox rawfox@freenet.de --- Setting libglesv2 to `buildin` in winecfg, solves the issue.
https://bugs.winehq.org/show_bug.cgi?id=49633
rawfox rawfox@freenet.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #13 from rawfox rawfox@freenet.de --- closed
https://bugs.winehq.org/show_bug.cgi?id=49633
Zeb Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |msvcrt Status|CLOSED |RESOLVED CC| |z.figura12@gmail.com Fixed by SHA1| |38c490496000c5852f14e9c0228 | |68c5107d9ff03 Regression SHA1| |f02193738c88bea8fefb3f8d2e7 | |9c5e9941f6b5a Keywords| |regression
--- Comment #14 from Zeb Figura z.figura12@gmail.com --- Nothing was fixed in wine.(In reply to Michael Clasen from comment #12)
Setting libglesv2 to `buildin` in winecfg, solves the issue.
Nothing was fixed in wine, so RESOLVED FIXED is not appropriate. (Also, please don't close bugs yourself; they will be closed when a release is made.)
Anyway, this bug report was unfortunately reused for multiple problems. Since the original problem was fixed, and the subsequent problems are tracked elsewhere (bug 50459, bug 44985), let's just treat this as related to the first issue, and mark it FIXED appropriately.
https://bugs.winehq.org/show_bug.cgi?id=49633
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #15 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 7.12.