[Bug 36745] New: Wine broken on FreeBSD
http://bugs.winehq.org/show_bug.cgi?id=36745 Bug ID: 36745 Summary: Wine broken on FreeBSD Product: Wine Version: 1.7.19 Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: ole32 Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com Wine no longer succeeds in creating the .wine prefix. So it qualifies as totally broken. A bisect shows that the commit that breaks it is: commit 473a3a47a7d02694e659760008c1856f305cd82c Author: Vincent Povirk <vincent(a)codeweavers.com> Date: Thu May 8 15:03:10 2014 -0500 server: Try to get a read lock if we can't get a write lock. However it in fact reveals existing bugs. What happens is this: 1) The above patch causes the locking operation in server/file.c to fail with ENOTSUP. 2) file_set_error() does not know about so it returns STATUS_UNSUCCESSFUL. 3) This bubbles up to FileLockBytesImpl_LockRegion() in dlls/ole32/filelockbytes.c which translates this to STG_E_ACCESSDENIED on the sole basis that it's not success! This is where the main bug is. 4) This then causes the caller, StorageImpl_LockRegionSync(), to think the file is locked already and so it loops until the file is unlocked. That's the infinite loop that breaks the .wine prefix creation. 5) Finally StorageImpl_LockRegionSync() is supposed to pause between attempts but it does not so this loop uses all the CPU. Patches for points 2, 3 and 5 at 11. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=36745 François Gouget <fgouget(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|wine-bugs(a)winehq.org |fgouget(a)codeweavers.com -- 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.
http://bugs.winehq.org/show_bug.cgi?id=36745 François Gouget <fgouget(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1| |473a3a47a7d02694e659760008c | |1856f305cd82c Severity|normal |critical -- 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.
http://bugs.winehq.org/show_bug.cgi?id=36745 --- Comment #1 from Vincent Povirk <madewokherd(a)gmail.com> --- When does FreeBSD fail with ENOTSUP? Should that be added as a "no locking on this fs" case on set_unix_lock? -- 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.
http://bugs.winehq.org/show_bug.cgi?id=36745 Vincent Povirk <madewokherd(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression CC| |madewokherd(a)gmail.com -- 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.
http://bugs.winehq.org/show_bug.cgi?id=36745 Michael Müller <michael(a)fds-team.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |michael(a)fds-team.de --- Comment #2 from Michael Müller <michael(a)fds-team.de> --- Hmm, I can not reproduce this issue. I ported Pipelight and some of our patches to FreeBSD just 2 weeks ago and everything works as intended (see https://pic.twitter.com/qKAaawl7G4 for a screenshot). I used the current git version so I definitely have the mentioned commit in my source tree. Seems like the main issue only appears under specific circumstances and is not a bug in general. Maybe it is related to the used filesystem, in my case it is UFS2. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=36745 François Gouget <fgouget(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|critical |normal --- Comment #3 from François Gouget <fgouget(a)codeweavers.com> --- Vincent wrote:
When does FreeBSD fail with ENOTSUP?
It appears to happen when the filesystem is NFS. $HOME/.wine is on a UFS filesystem of course. However Wine is being run from a checkout which is on an NFS filesystem. And this failure indicates that Wine locks some file in there while creating the wineprefix. (Inferred because the bug disappears if I copy that tree to $HOME) At least I'm downgrading the importance of the bug.
Should that be added as a "no locking on this fs" case on set_unix_lock?
I guess that could make sense. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=36745 --- Comment #4 from François Gouget <fgouget(a)codeweavers.com> --- For reference here is the related set of patches (try 1 at least): * ole32: Fix StorageImpl_LockRegionSync() to actually wait between locking attempts. http://www.winehq.org/pipermail/wine-patches/2014-June/133042.html * server: Map ENOTSUP to STATUS_NOT_SUPPORTED. http://www.winehq.org/pipermail/wine-patches/2014-June/133043.html * ole32: Return the correct error in FileLockBytesImpl_*LockRegion*(). http://www.winehq.org/pipermail/wine-patches/2014-June/133044.html The last one is the most important one of the three. Even though it could be replaced by changing a set_unix_lock() to handle ENOTSUP like ENOLCK, I think it's still correct. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=36745 --- Comment #5 from Vincent Povirk <madewokherd(a)gmail.com> --- I think we should change ENOTSUP handling in set_unix_lock in addition to those three things. Please make sure you run the ole32:storage32 and kernel32:file tests with your changes. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=36745 François Gouget <fgouget(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Wine broken on FreeBSD |Wine broken on FreeBSD+NFS -- 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.
http://bugs.winehq.org/show_bug.cgi?id=36745 --- Comment #6 from François Gouget <fgouget(a)codeweavers.com> --- I have sent a patch to handle ENOTSUP as you suggested in set_unix_lock(). I have also run the ole32:storage32 and kernel32:file tests and noticed get_lock_error() did not handle STG_E_LOCKVIOLATION and that neither did the upper levels. So I changed that and now the tests pass fine on both FreeBSD and Linux (well, on FreeBSD ole32:storage32 gets the same 7 unrelated failures as before). * wineserver: Treat ENOTSUP the same way as ENOLCK, consider locking to be non-functional on that filesystem. http://www.winehq.org/pipermail/wine-patches/2014-June/133102.html * [1/2] ole32: Treat STG_E_LOCKVIOLATION the same way as STG_E_ACCESSDENIED as both indicate locking contention. http://www.winehq.org/pipermail/wine-patches/2014-June/133103.html * [2/2] ole32: Return the correct error in FileLockBytesImpl_*LockRegion*(). http://www.winehq.org/pipermail/wine-patches/2014-June/133104.html -- 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.
http://bugs.winehq.org/show_bug.cgi?id=36745 François Gouget <fgouget(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from François Gouget <fgouget(a)codeweavers.com> --- The fix has been committed so now we get WineTest results on FreeBSD again :-) The main commit is this one: commit f4c7e6d607d15c681daa60cfb12b128e4376b809 Author: Francois Gouget <fgouget(a)free.fr> Date: Wed Jun 18 17:53:06 2014 +0200 server: Treat ENOTSUP the same way as ENOLCK, consider locking to be non-functional on that filesystem. Also related are: commit 082d0910290e609a58ccd1c7c6d5b866f36c6ca6 Author: Francois Gouget <fgouget(a)free.fr> Date: Wed Jun 18 17:55:13 2014 +0200 ole32: Return the correct error in FileLockBytesImpl_*LockRegion*(). commit bea2c6f2d5a345b3e1b1a534eaa65fd80d429caf Author: Francois Gouget <fgouget(a)free.fr> Date: Wed Jun 18 17:53:48 2014 +0200 ole32: Treat STG_E_LOCKVIOLATION the same way as STG_E_ACCESSDENIED as both indicate locking contention. commit 809b6aeab2c6cfa4ec2a24137f316353fd28f37d Author: Francois Gouget <fgouget(a)free.fr> Date: Mon Jun 16 18:23:41 2014 +0200 ole32: Fix StorageImpl_LockRegionSync() to actually wait between locking attempts. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=36745 Bruno Jesus <00cpxxx(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |f4c7e6d607d15c681daa60cfb12 | |b128e4376b809 -- 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=36745 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #8 from Alexandre Julliard <julliard(a)winehq.org> --- Closing bugs fixed in 1.7.21. -- 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