[Bug 51479] New: Сreating a prefix gives "wine: Unhandled page fault on write access ..."
https://bugs.winehq.org/show_bug.cgi?id=51479 Bug ID: 51479 Summary: Сreating a prefix gives "wine: Unhandled page fault on write access ..." Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: minor Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: lvb.crd(a)protonmail.com CC: rbernon(a)codeweavers.com Regression SHA1: b065daa600e858823944f996144ed233065da7fd Distribution: ArchLinux When closing winecfg after creating a prefix (I mean run winecfg without prefix), now every time this message appears in the terminal: wine: Unhandled page fault on write access to 0000000000000000 at address 00007F6E5819F9BB (thread 00d0), starting debugger... Not sure if this is causing any negative consequences, and I have not found any similar descriptions among the recent issues. Bisecting tests indicate that it started after this patch series: https://github.com/wine-mirror/wine/commits/f24c8c75fe11fc4b928d3ec45e71ea7d... Specific commit: b065daa600e858823944f996144ed233065da7fd bad e3b28631485a010219928a888fcc543a5bb3c61d good I am using the build environment that Archlinux provides. If possible please let me know if someone can reproduce this. Thanks. -- 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=51479 Dmitry Skvortsov (Iglu47) <lvb.crd(a)protonmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression -- 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=51479 Dmitry Skvortsov (Iglu47) <lvb.crd(a)protonmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Сreating a prefix gives |Closing winecfg with fresh |"wine: Unhandled page fault |prefix creation gives |on write access ..." |"wine: Unhandled page fault | |on write access ..." -- 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=51479 Lorenzo Ferrillo <lorenzofer(a)live.it> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lorenzofer(a)live.it --- Comment #1 from Lorenzo Ferrillo <lorenzofer(a)live.it> --- Confirming, same bisection result. Reverting the commit on master fix the issue -- 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=51479 Gijs Vermeulen <gijsvrm(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Version|unspecified |6.13 -- 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=51479 Zebediah Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Closing winecfg with fresh |winedevice.exe crashes on |prefix creation gives |prefix shutdown |"wine: Unhandled page fault | |on write access ..." | CC| |z.figura12(a)gmail.com Component|-unknown |pnpmgr -- 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=51479 Zebediah Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dark.shadow4(a)web.de --- Comment #2 from Zebediah Figura <z.figura12(a)gmail.com> --- *** Bug 51569 has been marked as a duplicate of this bug. *** -- 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=51479 Zebediah Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fgouget(a)codeweavers.com --- Comment #3 from Zebediah Figura <z.figura12(a)gmail.com> --- *** Bug 51573 has been marked as a duplicate of this bug. *** -- 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=51479 François Gouget <fgouget(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #4 from François Gouget <fgouget(a)codeweavers.com> --- Adding some details from my duplicate bug report... As far as I can tell this issue is not caused by a specific process so a simple way to reproduce it is to run something like: $ ./wine hostname.exe /? INTEL-MESA: warning: Haswell Vulkan support is incomplete Usage : hostname $ wine: Unhandled page fault on write access to 00000000 at address 7E95C4D1 (thread 0070), starting debugger... 0070:err:seh:start_debugger Couldn't start debugger L"winedbg --auto 96 64" (1115) Read the Wine Developers Guide on how to set up winedbg or another debugger winedbg.exe is not really usable because it prevents Wine from shutting down and winedevice.exe from exiting. But tracing showed that the crash happens in the libusb_close() call of fdo_pnp() in dlls/wineusb.sys/wineusb.c: https://source.winehq.org/git/wine.git/blob/HEAD:/dlls/wineusb.sys/wineusb.c... This is with Debian's version 2:1.0.22-2 of the libusb-1.0-0 and libusb-1.0-0-dev packages. All I found online is that libusb_close() typically crashes when there are control transfers still in progress. So maybe this is a cleanup issue? Since this started with b065daa600 which changed the shutdown procedure, maybe this is related to the cleanup issue mentioned above. -- 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=51479 --- Comment #5 from Rémi Bernon <rbernon(a)codeweavers.com> --- The problem is that the device get removed twice, once in each individual PDO IRP_MN_REMOVE_DEVICE, and then in the FDO IRP_MN_REMOVE_DEVICE, which again closes device from the device list. The PDO IRP_MN_REMOVE_DEVICE doesn't remove the entry from the list, so the devices are closed twice. I think it didn't happen before the change because ntoskrnl was blocked on exit on hidclass device removal and was then killed after a bit, waiting forever for the hid reading thread to exit, and so didn't even tried to remove wineusb devices. Or something along those lines. A patch to address this has been proposed (https://source.winehq.org/patches/data/210666), but rejected. -- 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=51479 François Gouget <fgouget(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch, source, testcase -- 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=51479 Gcenx <gcenx83(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gcenx83(a)gmail.com --- Comment #6 from Gcenx <gcenx83(a)gmail.com> --- This also affe(In reply to Rémi Bernon from comment #5)
The problem is that the device get removed twice, once in each individual PDO IRP_MN_REMOVE_DEVICE, and then in the FDO IRP_MN_REMOVE_DEVICE, which again closes device from the device list. The PDO IRP_MN_REMOVE_DEVICE doesn't remove the entry from the list, so the devices are closed twice.
I think it didn't happen before the change because ntoskrnl was blocked on exit on hidclass device removal and was then killed after a bit, waiting forever for the hid reading thread to exit, and so didn't even tried to remove wineusb devices. Or something along those lines.
A patch to address this has been proposed (https://source.winehq.org/patches/data/210666), but rejected.
Strange it got rejected as that also resolved the issue on macOS. -- 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=51479 --- Comment #7 from Zebediah Figura <z.figura12(a)gmail.com> --- (In reply to Gcenx from comment #6)
This also affe(In reply to Rémi Bernon from comment #5)
The problem is that the device get removed twice, once in each individual PDO IRP_MN_REMOVE_DEVICE, and then in the FDO IRP_MN_REMOVE_DEVICE, which again closes device from the device list. The PDO IRP_MN_REMOVE_DEVICE doesn't remove the entry from the list, so the devices are closed twice.
I think it didn't happen before the change because ntoskrnl was blocked on exit on hidclass device removal and was then killed after a bit, waiting forever for the hid reading thread to exit, and so didn't even tried to remove wineusb devices. Or something along those lines.
A patch to address this has been proposed (https://source.winehq.org/patches/data/210666), but rejected.
Strange it got rejected as that also resolved the issue on macOS.
Unfortunately the patch doesn't do the right thing in all cases; see <https://www.winehq.org/pipermail/wine-devel/2021-August/191749.html>. Also unfortunately I haven't gotten around to checking native behaviour yet. -- 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=51479 --- Comment #8 from Gcenx <gcenx83(a)gmail.com> --- (In reply to Zebediah Figura from comment #7)
Unfortunately the patch doesn't do the right thing in all cases; see <https://www.winehq.org/pipermail/wine-devel/2021-August/191749.html>. Also unfortunately I haven't gotten around to checking native behaviour yet.
So it’s better to revert the offending commit or just skip building with libusb until this gets resolved in a correct manner. -- 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=51479 --- Comment #9 from Rémi Bernon <rbernon(a)codeweavers.com> --- I understand that it may not be the right thing to do, but reading the driver documentation doesn't make it very much clearer to me what the right thing is. The patch seems pretty safe to me, and I don't really see how this is so bad. It may unlink an already unlinked device but that shouldn't cause any issue. It also solves an ugly crash on exit, which I think is desirable even if it's a temporary solution before a more proper fix. -- 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=51479 --- Comment #10 from Zebediah Figura <z.figura12(a)gmail.com> --- (In reply to Rémi Bernon from comment #9)
I understand that it may not be the right thing to do, but reading the driver documentation doesn't make it very much clearer to me what the right thing is.
The patch seems pretty safe to me, and I don't really see how this is so bad. It may unlink an already unlinked device but that shouldn't cause any issue. It also solves an ugly crash on exit, which I think is desirable even if it's a temporary solution before a more proper fix.
Unlinking an already unlinked device is its own crash. I'm currently looking into the right way to solve this. -- 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=51479 --- Comment #11 from Rémi Bernon <rbernon(a)codeweavers.com> --- Oh okay, I was really persuaded that list_remove was resetting the pointers too... although it doesn't. Worrying. -- 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=51479 Julian Rüger <jr98(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jr98(a)gmx.net -- 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=51479 Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mikes(a)guam.net --- Comment #12 from Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> --- *** Bug 51527 has been marked as a duplicate of this bug. *** -- 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=51479 Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |o.dierick(a)piezo-forte.be --- Comment #13 from Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> --- (In reply to Gcenx from comment #8)
(In reply to Zebediah Figura from comment #7)
Unfortunately the patch doesn't do the right thing in all cases; see <https://www.winehq.org/pipermail/wine-devel/2021-August/191749.html>. Also unfortunately I haven't gotten around to checking native behaviour yet.
So it’s better to revert the offending commit or just skip building with libusb until this gets resolved in a correct manner.
Hello, FYI, I build wine --without-usb and I get the issue too, so that doesn't work around the issue. Regards. -- 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=51479 --- Comment #14 from Gcenx <gcenx83(a)gmail.com> --- (In reply to Olivier F. R. Dierick from comment #13)
Hello,
FYI, I build wine --without-usb and I get the issue too, so that doesn't work around the issue.
Regards.
This should have been resolved via b6a20450f47807a162318ef63e50278488d146f5 Are you saying the issue still remains in wine-6.16? -- 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=51479 --- Comment #15 from Zebediah Figura <z.figura12(a)gmail.com> --- (In reply to Gcenx from comment #14)
(In reply to Olivier F. R. Dierick from comment #13)
Hello,
FYI, I build wine --without-usb and I get the issue too, so that doesn't work around the issue.
Regards.
This should have been resolved via b6a20450f47807a162318ef63e50278488d146f5
Are you saying the issue still remains in wine-6.16?
Unfortunately a similar problem probably affects winebus. -- 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=51479 --- Comment #16 from Dmitry Skvortsov (Iglu47) <lvb.crd(a)protonmail.com> --- I do not know about similar problems, but I confirm that the initially described problem disappeared on b6a20450f47807a162318ef63e50278488d146f5. I did tests on Wine-6.15.r209.g33f7b14c6c8 and Wine-6.15.r210.gb6a20450f47. The version of the libusb 1.0.24-2 package for my distribution has not changed during all this time. On the current tag Wine-6.21, I also did not encounter this problem. -- 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=51479 Rémi Bernon <rbernon(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |b6a20450f47807a162318ef63e5 | |0278488d146f5 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #17 from Rémi Bernon <rbernon(a)codeweavers.com> --- Marking it as fixed then, please reopen if the problem still happens. -- 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=51479 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #18 from Alexandre Julliard <julliard(a)winehq.org> --- Closing bugs fixed in 7.0-rc2. -- 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)
-
WineHQ Bugzilla