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@winehq.org Reporter: fgouget@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@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.
http://bugs.winehq.org/show_bug.cgi?id=36745
François Gouget fgouget@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Assignee|wine-bugs@winehq.org |fgouget@codeweavers.com
http://bugs.winehq.org/show_bug.cgi?id=36745
François Gouget fgouget@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1| |473a3a47a7d02694e659760008c | |1856f305cd82c Severity|normal |critical
http://bugs.winehq.org/show_bug.cgi?id=36745
--- Comment #1 from Vincent Povirk madewokherd@gmail.com --- When does FreeBSD fail with ENOTSUP? Should that be added as a "no locking on this fs" case on set_unix_lock?
http://bugs.winehq.org/show_bug.cgi?id=36745
Vincent Povirk madewokherd@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression CC| |madewokherd@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=36745
Michael Müller michael@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |michael@fds-team.de
--- Comment #2 from Michael Müller michael@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.
http://bugs.winehq.org/show_bug.cgi?id=36745
François Gouget fgouget@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|critical |normal
--- Comment #3 from François Gouget fgouget@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.
http://bugs.winehq.org/show_bug.cgi?id=36745
--- Comment #4 from François Gouget fgouget@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.
http://bugs.winehq.org/show_bug.cgi?id=36745
--- Comment #5 from Vincent Povirk madewokherd@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.
http://bugs.winehq.org/show_bug.cgi?id=36745
François Gouget fgouget@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Wine broken on FreeBSD |Wine broken on FreeBSD+NFS
http://bugs.winehq.org/show_bug.cgi?id=36745
--- Comment #6 from François Gouget fgouget@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
http://bugs.winehq.org/show_bug.cgi?id=36745
François Gouget fgouget@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED
--- Comment #7 from François Gouget fgouget@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@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@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@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@free.fr Date: Mon Jun 16 18:23:41 2014 +0200
ole32: Fix StorageImpl_LockRegionSync() to actually wait between locking attempts.
http://bugs.winehq.org/show_bug.cgi?id=36745
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |f4c7e6d607d15c681daa60cfb12 | |b128e4376b809
https://bugs.winehq.org/show_bug.cgi?id=36745
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #8 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 1.7.21.
-
wine-bugs＠winehq.org