[Bug 46218] New: World of Warcraft A streaming error has occurred. ( WOW51900322) - wine-staging
https://bugs.winehq.org/show_bug.cgi?id=46218 Bug ID: 46218 Summary: World of Warcraft A streaming error has occurred. (WOW51900322) - wine-staging Product: Wine-staging Version: 3.21 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: o.dierick(a)piezo-forte.be CC: leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com Distribution: --- World of Warcraft kicks the player back to the login screen with the error "A streaming error has occurred. (WOW51900322)" a few seconds after choosing a character and entering the game world. The issue has been reported on the AppDB, WineHQ forums and eu/us blizzard forums. The issue affects Linux players only. See the How-to / Notes section of https://appdb.winehq.org/objectManager.php?sClass=version&iId=36961 The workaround is to remove and replace the Cache directory in Program Files (x86)\World of Warcraft\ by a Windows copy of the cache. I experience the issue since I upgraded to Debian 9 and got rid of bug 42874. I made several tests and pin-pointed the issue to the creaturecache.wdb and gameobjectcache.wdb in World of Warcraft\Cache\WDB\ being corrupt when created. I compiled a custom wine version : plain wine 3.21 + staged patchset from bug 45349 (with its staging dependencies). With that custom version the Cache files are NOT corrupt and the issue doesn't happen. The 64-bit client requires wine-staging (bug 45349). I have no knowledge of the issue with 32 bit version of the client and can't test it myself due to (abandoned) bug 43656. If the bug is indeed a regression in wine-staging, I guess people using wine-staging to run the 32 bit game client also have the issue. I'm currently conducting a regression test in wine-staging to pin-point the patchset that causes the wrong file creation. -- 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=46218 Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression URL| |https://eu.battle.net/accou | |nt/download/ -- 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=46218 Sveinar Søpler <cybermax(a)dexter.no> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |cybermax(a)dexter.no --- Comment #1 from Sveinar Søpler <cybermax(a)dexter.no> --- This is something that only happens for SOME people (or possibly SOME linux distro's.. or SOME kernels) i guess. I have cleared out the cache MANY times, and never had this issue. Then again, i rarely use regular wined3d dx11, but either using DXVK, or of late i also done some d3d12 w/vkd3d. I think its kinda hard to troubleshoot this issue, as its not pinpointed to a specific wine version? Could it be related to kernel? Possibly some starved IO thing in the scheduler perhaps? I've tended to use "deadline" scheduler back when i had a spinning disc for WoW, but lastly i have a nvme drive, and just use "none". Just thinking if it is some sort of data corruption in the files, it could be some weird cache flushing issue submitted from the kernel? Just suggesting, cos i have used wine with WoW since pre. 2.x, and tend to test git versions of wine and all kinds of weird patches i find for wine and never had that issue. Atm i use wine-tkg-3.21 w/ESYNC patches (same as Lutris uses xept i compile myself). -- 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=46218 Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |erich.e.hoover(a)gmail.com --- Comment #2 from Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> --- Regression testing is finished. The issue doesn't occur with wine-staging minus patchset server-Inherited_ACLs. I double checked and get 100% consistent results. The patchset contains one patch "server: Inherit security attributes from parent directories on creation. (try 7)" by Erich E. Hoover. CCing Erich E. Hoover. -- 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=46218 --- Comment #3 from Sveinar Søpler <cybermax(a)dexter.no> --- Interesting. I use this patch, and have never had this issue... So could this be related to some weird filesystem permission then? Do you have the WoW installed on a separate drive perhaps? Eg. sdb1 mounted as /home/yourname/games or something like that? /home/ on a separate disc? Might be some ppl have their wineprefixe's on separate drives due to space or whatnot, and something goes avry with this patch and permissions somehow? Would be interesting to find out if something like that happens, especially since its clearly not a 100% case, but happens for SOME ppl. -- 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=46218 --- Comment #4 from Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> --- Disk structure is on a single drive: /dev/sda1 - ext4 primary partition Debian 8 (16GB) /dev/sda3 - ext4 primary partition Debian 9 (16GB) /dev/sda2 - extended partition: (968GB) /dev/sda5 - swap partition (17GB) /dev/sda6 - ext4 partition (951GB) Debian 8 : /dev/sda1 mounted as / /dev/sda6 mounted as /home/ /dev/sda5 is swap wineprefix is a directory under /home/ Debian 9 : /dev/sda3 mounted as / (includes /home/) /dev/sda5 is swap /dev/sda6 is mounted in /media/<username>/<sda6 UUID> wineprefix is a symlink under /home/ that points to the prefix in /media/<username>/<sda6 UUID>. The wine versions used were compiled in respective Debian 8 and Debian 9 build environments. Result is same in both systems: wine-staging → stream error. wine-staging minus server-Inherited_ACLs patchset → no stream error. -- 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=46218 --- Comment #5 from Sveinar Søpler <cybermax(a)dexter.no> --- It would be interesting to see more ppl with this problem post their setups perhaps? I use a simple setup with /dev/nvme0n1p1 -> /boot/efi, and /dev/nvme0n1p2 -> / So no different disc mounted for /home , or /winegames or stuff like that. I dont argue that one should NOT mount a own partition for wineprefixes or things like that, cos that is infact a great way to keep things secure from crashes and whatnot... Its just that i am not able at all to cause this error, and seeing what that patch is about, it is something to do with Access Control of files. If something weird happens when wine tries to read permissions from a folder.. that is on a different drive than the "parent mount" maybe something weird happens? Especially with symlinked folders perhaps? I dunno.. Ill see if can test this here with a mounted partition instead... although moving 60'ish or so GB around is kinda crap :( -- 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=46218 Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |NOTOURBUG --- Comment #6 from Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> --- I can no longer reproduce the issue after the game updated to version 8.1.0 (28833), even when going back to wine-staging 3.21. Resolving NOTOURBUG because the issue was fixed by a game update (without changing anything else). -- 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=46218 lavadrop <jorge.blasio(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jorge.blasio(a)gmail.com --- Comment #7 from lavadrop <jorge.blasio(a)gmail.com> --- I keep getting disconnected, the bug is still happening to me on 3.21 staging -- 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=46218 Zebediah Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|NOTOURBUG |ABANDONED --- Comment #8 from Zebediah Figura <z.figura12(a)gmail.com> --- (In reply to Olivier F. R. Dierick from comment #6)
Resolving NOTOURBUG because the issue was fixed by a game update (without changing anything else).
I think ABANDONED is more appropriate here. (In reply to lavadrop from comment #7)
I keep getting disconnected, the bug is still happening to me on 3.21 staging
Is this the case after updating to version 8.1.0? -- 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=46218 --- Comment #9 from Zebediah Figura <z.figura12(a)gmail.com> --- Unfortunately this means that we are going to lose a test case for a bisected regression. Sadly I am not familiar with the patch set in question, but so as to at least get some information, can someone who can still reproduce the bug please attach a trace with +server,+file,+ntdll,+advapi? -- 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=46218 Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|ABANDONED |WORKSFORME --- Comment #10 from Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> --- (In reply to Zebediah Figura from comment #8)
I think ABANDONED is more appropriate here.
Not wanting to nitpick but I think WORKSFORME is more appropriate, because the bug disappeared for me and we have no clues what may have caused it. Comment 7 shows that other people still have the issue and the bug is taken care of, so it's not ABANDONED. ABANDONED: "No one took care of the bug for a long time and the reporter didn't reply to information requests. If more information appears later, the bug can be reopened." WORKSFORME: "All attempts at reproducing this bug were futile, and reading the code produces no clues as to why the described behavior would occur. If more information appears later, the bug can be reopened." (In reply to Zebediah Figura from comment #9)
Unfortunately this means that we are going to lose a test case for a bisected regression. Sadly I am not familiar with the patch set in question, but so as to at least get some information, can someone who can still reproduce the bug please attach a trace with +server,+file,+ntdll,+advapi?
Sound like you need info to get clues "as to why the described behavior would occur" → WORKSFORME unless someone can reproduce. -- 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=46218 --- Comment #11 from Zebediah Figura <z.figura12(a)gmail.com> --- (In reply to Olivier F. R. Dierick from comment #10)
(In reply to Zebediah Figura from comment #8)
I think ABANDONED is more appropriate here.
Not wanting to nitpick but I think WORKSFORME is more appropriate, because the bug disappeared for me and we have no clues what may have caused it. Comment 7 shows that other people still have the issue and the bug is taken care of, so it's not ABANDONED.
That works I guess; it's just that we tend to reserve NOTOURBUG for bugs in libraries that Wine depends on. Clearly there is a bug in Wine here, as it works on Windows. I've seen ABANDONED used sometimes for this purpose, because the reporter is in some sense forced to "abandon" the report. -- 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=46218 --- Comment #12 from Erich E. Hoover <erich.e.hoover(a)gmail.com> --- (In reply to Olivier F. R. Dierick from comment #2)
Regression testing is finished.
The issue doesn't occur with wine-staging minus patchset server-Inherited_ACLs.
I double checked and get 100% consistent results.
The patchset contains one patch "server: Inherit security attributes from parent directories on creation. (try 7)" by Erich E. Hoover.
CCing Erich E. Hoover.
Going through email that I should have read sooner... Okay, what probably is happening here is that the prefix was created without wine-staging and then run with it. The aforementioned patch applies the inheritable security attributes of the parent folder to new children, which is the way SDs are supposed to work. The security descriptors work best if you don't switch back and forth between regular wine and wine-staging, since wine's default security descriptors can be problematic if copied, but this generally only affects applications that are incredibly picky. It's also possible that the security descriptor for the Cache folder is wrong, which would make it only work if wine-staging _doesn't_ create Cache because later when wine-staging copies its security descriptors then it restricts the children incorrectly. So, if someone is willing to investigate then I would suggest: 1) create a fresh prefix with wine-staging and try the game with wine-staging 2) create a fresh prefix with regular wine and then try the game with wine-staging 3) create a fresh prefix with wine-staging and try the game with regular wine Depending on which of these scenarios work then that would narrow down whether the issue is in the security descriptor for Cache or sharing a prefix between regular wine and wine-staging. -- 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=46218 --- Comment #13 from lavadrop <jorge.blasio(a)gmail.com> --- Created attachment 63194 --> https://bugs.winehq.org/attachment.cgi?id=63194 Lutris debug log -- 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=46218 --- Comment #14 from lavadrop <jorge.blasio(a)gmail.com> --- I am running the latest WoW Battle for Azeroth version using lutris with a tkg 3.21 x64 prefix with DXVK .094 and esync enabled. I can reproduce the bug with or without addons by opening the tailoring UI and clicking on the Enhanced Deep Sea Breeches recipe. Sometimes, that won't trigger the bug and all the recipes can be browsed. However, when that happens, teleporting to another location in the game (triggering the loading of assets) will crash the game again in the same fashion. Upon restarting the game and loggin g in, the game world loads fine, but opening the tailoring UI and selecting the recipe crashes the game again with the same error. -- 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=46218 --- Comment #15 from Erich E. Hoover <erich.e.hoover(a)gmail.com> --- (In reply to lavadrop from comment #14)
I am running the latest WoW Battle for Azeroth version using lutris with a tkg 3.21 x64 prefix with DXVK .094 and esync enabled. ...
Does the workaround Olivier suggested in the first post work (copying the cache from a Windows computer)? If so then we might be able to find out what is going on by examining (or clearing) the extended attribute that stores the security descriptor. -- 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=46218 --- Comment #16 from lavadrop <jorge.blasio(a)gmail.com> --- Nope, both the cache from GitHub and the one generated by WoW’s Wine prefix suffer from the same bug. Just to be clear, Wine does not crash anymore by using it’s own generated cache. -- 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=46218 --- Comment #17 from Erich E. Hoover <erich.e.hoover(a)gmail.com> --- (In reply to lavadrop from comment #16)
Nope, both the cache from GitHub and the one generated by WoW’s Wine prefix suffer from the same bug. Just to be clear, Wine does not crash anymore by using it’s own generated cache.
Then I'm missing something, is this a separate problem? Are you still getting the message "A streaming error has occurred. (WOW51900322)"? -- 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=46218 --- Comment #18 from lavadrop <jorge.blasio(a)gmail.com> --- Yes, but when the bug was first reported, WoW would crash immediately after loading a character. Now it crashes when loading inventory items from vendors, crafting items and transmogrifier items. -- 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=46218 --- Comment #19 from Sveinar Søpler <cybermax(a)dexter.no> --- @lavadrop What API are you running WoW with? DX12(vkd3d), DX11(dxvk) or DX11(WineD3D). I have not experienced any streaming errors ever, but do not have tailoring on any of my characters.. but i do browse the transmog ui quite a bit fiddling with various transmog setups. Lately (as of Wine4.0-RCx) i have used vkd3d w/DX12 mostly tho. Staging+Esync patchset. Not sure how the WoW cache is built, but it SHOULD not depend on dxvk/wined3d... but it COULD depend on DX11 / DX12 when being generated? Anyone know? Kind of hard to compare, as the cache is being built from what you see i guess, so if one should compare the cache from DX11 vs DX12, i think a totally remote location devoid of random entities (mobs/players/whatever). Anyone know if this is just a "shader cache totally independent of API selection", or if the cache is generated differently when switching API's? -- 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=46218 --- Comment #20 from lavadrop <jorge.blasio(a)gmail.com> --- (In reply to Sveinar Søpler from comment #19)
@lavadrop What API are you running WoW with? DX12(vkd3d), DX11(dxvk) or DX11(WineD3D).
I have not experienced any streaming errors ever, but do not have tailoring on any of my characters.. but i do browse the transmog ui quite a bit fiddling with various transmog setups.
Lately (as of Wine4.0-RCx) i have used vkd3d w/DX12 mostly tho. Staging+Esync patchset.
Not sure how the WoW cache is built, but it SHOULD not depend on dxvk/wined3d... but it COULD depend on DX11 / DX12 when being generated? Anyone know?
Kind of hard to compare, as the cache is being built from what you see i guess, so if one should compare the cache from DX11 vs DX12, i think a totally remote location devoid of random entities (mobs/players/whatever).
Anyone know if this is just a "shader cache totally independent of API selection", or if the cache is generated differently when switching API's?
Sorry, I must've missed new message notifications. I'm using DXVK with the lutris.net provided install script and tkg build 3.21. I haven't tried RC builds. However, like it was mentioned before, I have a multi volume linux setup, with all my games residing on a spinning 2 TB HDD. My system is: dev/sda1 mounted as / ext4 dev/sdb1 mounted as /home ext4 -- 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=46218 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #21 from Austin English <austinenglish(a)gmail.com> --- Closing. -- 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)
-
wine-bugs＠winehq.org