https://bugs.winehq.org/show_bug.cgi?id=50229
Bug ID: 50229 Summary: Battle.net launcher sometimes crashes after login (wine-5.22) Product: Wine-staging Version: 5.22 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: kolAflash@kolahilft.de CC: leslie_alistair@hotmail.com, z.figura12@gmail.com Distribution: ---
Created attachment 68736 --> https://bugs.winehq.org/attachment.cgi?id=68736 STDOUT / STDERR log
Since upgrading from wine-staging-5.21*, the Battle.net launcher crashes after login in about 1 of 3 times. After the crash, the Blizzard crash reporter comes up.
I've enabled the virtual desktop via winecfg and I'm running Battle.net by executing:
explorer.exe /desktop=shell,1920x1080 "C:\Program Files (x86)\StarCraft II\StarCraft II.exe"
I'm using a dual monitor setup. And I think the crash might only happen if I move the mouse out of the virtual desktop to my second monitor AFTER entering my password in the Battle.net login dialog. Sadly the bug isn't completely deterministic. So I need some more time for detailed testing.
Wine version: wine-staging-5.22** I've attached the STDOUT / STDERR log, created with: WINEDEBUG=+pid,+loaddll,+timestamp,+seh
*including patches for: https://bugs.winehq.org/show_bug.cgi?id=49782 https://bugs.winehq.org/show_bug.cgi?id=50110
**including patches for: https://bugs.winehq.org/show_bug.cgi?id=49782
https://bugs.winehq.org/show_bug.cgi?id=50229
--- Comment #1 from kolAflash kolAflash@kolahilft.de --- Maybe related: https://bugs.winehq.org/show_bug.cgi?id=50114
https://bugs.winehq.org/show_bug.cgi?id=50229
Maciej Stanczew maciej.stanczew+b@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |maciej.stanczew+b@gmail.com
--- Comment #2 from Maciej Stanczew maciej.stanczew+b@gmail.com --- I can confirm this, I also started seeing Battle.net crash after recent Wine update. But the reproduction is very random, so I wasn't able to do any useful bisection. I had it happen a couple of times just after launching the app (I use autologin), once when switching between games, and once when exiting the app.
https://bugs.winehq.org/show_bug.cgi?id=50229
Olivier F. R. Dierick o.dierick@piezo-forte.be changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |o.dierick@piezo-forte.be URL| |https://www.blizzard.com/en | |-us/apps/battle.net/desktop Product|Wine-staging |Wine Component|-unknown |-unknown Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Keywords| |download
--- Comment #3 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- Hello,
Confirming with vanilla wine 5.22 and up-to-date 32-bit Blizzard Battle.net.
Moving to wine product.
Regards.
https://bugs.winehq.org/show_bug.cgi?id=50229
Sveinar Søpler cybermax@dexter.no changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |cybermax@dexter.no
--- Comment #4 from Sveinar Søpler cybermax@dexter.no --- (In reply to Olivier F. R. Dierick from comment #3)
Hello,
Confirming with vanilla wine 5.22 and up-to-date 32-bit Blizzard Battle.net.
Moving to wine product.
Regards.
I actually had this problem too with wine-staging-5.22, but did not test wine-dev.
However, after this staging commit: https://github.com/wine-staging/wine-staging/commit/f257f37b92041fc718de04aa... i have not had this happen again.
I cannot guarantee this is the solution, since you confirm this with wine-dev, as if this is a non-frequent random occurrance, i might have just been lucky 50+ times since then :)
PS. I am not aware if this staging patch somehow fixes something in wine-dev, or if it is a completely new function only found in -staging (that got fixed with this commit). Worth checking perhaps?
https://bugs.winehq.org/show_bug.cgi?id=50229
--- Comment #5 from Maciej Stanczew maciej.stanczew+b@gmail.com --- I am using Staging 5.22 with f257f37b92041fc718de04aa83ec3139b748ffa2, and I did experience the issue on this build. But, for me the reproduction really seems to be completely random.
Just 2 days ago I had what seemed to be 100% reproduction. Either immediately at launch, or after a couple of minutes, Battle.net would crash. This was during updating the game -- maybe it's related somehow.
I gathered logs, then reverted to Staging 5.21; launched Battle.net, and had it running for over 2 hours without any crashes. I then updated back to 5.22 + f257f37b92041fc718de04aa83ec3139b748ffa2, and… also have not seen any crashes since then.
https://bugs.winehq.org/show_bug.cgi?id=50229
--- Comment #6 from Maciej Stanczew maciej.stanczew+b@gmail.com --- Created attachment 68764 --> https://bugs.winehq.org/attachment.cgi?id=68764 Log Staging 5.22 + f257f37b, crash
https://bugs.winehq.org/show_bug.cgi?id=50229
--- Comment #7 from Maciej Stanczew maciej.stanczew+b@gmail.com --- Created attachment 68765 --> https://bugs.winehq.org/attachment.cgi?id=68765 Log Staging 5.22 + f257f37b, no crash
https://bugs.winehq.org/show_bug.cgi?id=50229
--- Comment #8 from Sveinar Søpler cybermax@dexter.no --- I am going to assume you build wine yourself since the patch i mentioned is used.
Just out of curiosity, could i ask the following: 1. What distro 2. What gcc/mingw-w64 version used 3. Configure line (for compilation flags).
I ask cos i had some strangeness happen with gcc-mingw-w64 (10.2) that made me change a couple of flags that worked fine with gcc-mingw-w64 (9.3).
https://bugs.winehq.org/show_bug.cgi?id=50229
--- Comment #9 from Maciej Stanczew maciej.stanczew+b@gmail.com --- That's a correct assumption ;) I am on Arch. I basically used Arch's PKGBUILD for this, minus some of the optional dependencies: https://github.com/archlinux/svntogit-community/blob/packages/wine-staging/t...
mingw versions at the time of build: installed = mingw-w64-binutils-2.35.1-1-x86_64 installed = mingw-w64-crt-8.0.0-1-any installed = mingw-w64-gcc-10.2.0-2-x86_64 installed = mingw-w64-headers-8.0.0-1-any installed = mingw-w64-winpthreads-8.0.0-1-any
For compilation parameters: CFLAGS and LDFLAGS are overriden like in PKGBUILD, and additionally I don't have "--with-gstreamer", but instead have "--without-gtk3". The resulting *FLAGS should be: CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe" LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro"
However initially after 5.22 release I have used the precompiled binaries from the repository, and I have also seen Battle.net crash with this build.
And just to confirm the randomness, yesterday and today I have been running Battle.net for a long time, launching and closing it multiple times, and I have not seen a single crash (on the same 5.22 + f257f37b version that one day earlier crashed like crazy).
https://bugs.winehq.org/show_bug.cgi?id=50229
--- Comment #10 from Sveinar Søpler cybermax@dexter.no --- The reason i asked was because i have found some instability when compiling with gcc-mingw-w64-10.2 and using flags like -mavx "or higher" (eg -march=native)
As long as the CFLAGS is near or the same as CROSSCFLAGS i would say it should be no problems with what you post :)
Not sure what would have changed with this from gcc-9.3 -> gcc-10.2, or if it is just some particular code and randomness that happened, but i have had issues when using -march=native with earlier wine versions that would randomly crash when playing WoW for instance.
I have had no problems so far today (but not tested long) with battle.net and WoW using staging-6.0-rc1.
https://bugs.winehq.org/show_bug.cgi?id=50229
--- Comment #11 from kolAflash kolAflash@kolahilft.de --- (In reply to Sveinar Søpler from comment #10)
The reason i asked was because i have found some instability when compiling with gcc-mingw-w64-10.2 and using flags like -mavx "or higher" (eg -march=native)
Compiled wine-staging-5.22 with CFLAGS='-march=amdfam10 -O2'. Adding CROSSCFLAGS='-march=amdfam10 -O2' didn't help. Removing CFLAGS and CROSSCFLAGS didn't help either.
I'm not 100 % sure. But I think my system is using gcc-10 since month. So there's been no gcc-9 -> gcc-10 migration between wine 5.21 and 5.22 here.
https://bugs.winehq.org/show_bug.cgi?id=50229
--- Comment #12 from Sveinar Søpler cybermax@dexter.no --- For each wine version of "late" there has been more and more .dll's compiled as PE libs.
This means that a library compiled in wine-21 might be compiled with gcc (winegcc), but in wine-22 it might have been converted to a PE lib compiled with mingw-w64.
One example of a situation where i noticed a difference between mingw-w64 versions was with DXVK. I used to compiled DXVK by replacing the -msse -msse2 lines with -march=native when using mingw-w64-9.3, but after upgrading to mingw-w64-10.2 running Unigine benchmarks simply crash upon starting. This (to me) kinda show there is a slight difference between 9.3 - 10.2 for mingw-w64 when generating PE libs.
Now, it may be more apparent functions in the d3d11 (DXVK) libs that crashes when using AVX or SSE3-4++ vs. wine libs, and without a test for this difference it is kind of hard to pinpoint i guess. Experiment a bit with this if you like.
But as i said, using -march=x86_64 -mtune=generic for CROSSCFLAGS should be perfectly fine tho.
https://bugs.winehq.org/show_bug.cgi?id=50229
--- Comment #13 from Sveinar Søpler cybermax@dexter.no --- This "AVX" issue is mostly for 32-bit binaries, and battle.net launcher is a 32-bit app.
https://sourceforge.net/p/mingw-w64/discussion/723797/thread/bc936130/
My theory would be - although probably a bit far fetched - that now that wine uses a lot more dll libs compiled as PE libs with mingw, SOME functions could cause issues with 32-bit apps if you compile with any -mavx or -march=native (given a recent processor) optimizations.
There is a bit of "default flags" changed for mingw-w64-9.3 -> mingw-w64-10.2 from what i can see, that could possibly cause issues when using the "same flags i have always done" after upgrading perhaps.
https://bugs.winehq.org/show_bug.cgi?id=50229
--- Comment #14 from kolAflash kolAflash@kolahilft.de --- I've run Battle.net about 10 times with wine-staging-6.0-rc1 and it seems like the bug is gone.
Can someone confirm?
https://bugs.winehq.org/show_bug.cgi?id=50229
Luke Bratch luke@bratch.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |luke@bratch.co.uk
https://bugs.winehq.org/show_bug.cgi?id=50229
EntropyWizard entropywizard@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |entropywizard@gmail.com
--- Comment #15 from EntropyWizard entropywizard@gmail.com --- I am running on Fedora Core 32 with the default wine packages, dxvk packages and the nvidia propriatary drivers. I was having battle crashes with version 5.22 almost every launch. A week or so ago wine-staging-6.0 made it into the updates for fedora core, since then I have had no battle net crashes at all.
https://bugs.winehq.org/show_bug.cgi?id=50229
kolAflash kolAflash@kolahilft.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|NEW |RESOLVED
--- Comment #16 from kolAflash kolAflash@kolahilft.de --- Last two comments look like this is resolved.
https://bugs.winehq.org/show_bug.cgi?id=50229
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #17 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 6.1.
-
WineHQ Bugzilla