Re: Handling page faults in syscalls
Stefan Dösinger via Wine-devel <[email protected]> Tue, 23 Dec 2025 10:18:59 +0300
| Newsgroups | gmane.comp.emulators.wine.devel |
|---|---|
| Message-ID | <5464877.31r3eYUQgx@strix> |
--nextPart5101416.LvFx2qVVIh Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8"; protected-headers="v1" From: Stefan =?UTF-8?B?RMO2c2luZ2Vy?= <[email protected]> To: [email protected] Cc: [email protected] Subject: Re: Handling page faults in syscalls Date: Tue, 23 Dec 2025 10:18:59 +0300 Message-ID: <5464877.31r3eYUQgx@strix> In-Reply-To: <[email protected]> References: <[email protected]> MIME-Version: 1.0 Am Dienstag, 23. Dezember 2025, 02:12:57 Ostafrikanische Zeit schrieb tblodt--- via Wine-devel: > My guess is these are caught instead of killing the process because that's > the expected behavior of an NT syscall when you pass a bad pointer to it - > that a bad dereference of a userspace pointer would be handled and turned > into returning an fault error code. Some of the unexpected syscall faults I debugged happened because of incorrectly set up host libraries - libGL segfaulting when trying to create a context, gnutls or kerberos crashing when trying to load them. Those are not necessary for the base functionality of Wine, so we don't want to crash and burn due to it. I don't know if that's the real reason for the silent swallowing of SIGSEGVs. It is something to keep in mind though when changing the behavior. I ran into cases myself where I wish I had gotten more obvious notifications. The Vulkan code has assert(!status) after most calls after basic initialization, which will make a syscall sigsegv fatal. On the other hand, a Windows-side STATUS_ACCESS_VIOLATION also won't print anything by default, there are many applications that generate a ton of them in their normal operation. --nextPart5101416.LvFx2qVVIh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQJPBAABCAA5FiEEQxb0tqoFWyeVMl1sPRO8yFRPGiIFAmlKQmMbFIAAAAAABAAO bWFudTIsMi41KzEuMTEsMiwyAAoJED0TvMhUTxoiI1IQAK+PtW6aQJN5WcQJy+x1 njDjXnZov52dSMYf9dPpoB7z9QNrYopWbwjsqgx8WpSQfuV0vVlRY3l4Yfnoh2qf bkRXVzgiwAFywmNpufkoT8NFoJERJqnfsjxn9dlvISljKK4r2QgO4nvilfwsnF3X aRh7caMiMhT9ibA9WDxRksIBoeyHJkpRdsUZmzrL3eWs5EAeltCKw5oXb9zdkpnu o5MsCA+8/iVRDycPwiAwmy6KGR4T979mj34VNrJDYkCreGr6ZU92MLxFD+ol8F4B RZwJkMfv2Pcq7dcPv7ubS3oY2/AW3oS5wjkCIISor/OFC5fiRMIPpFXVZFPorMar rtj2yvE71YpRpp/ROlrLkBZwK4rdiYicpQskLdaZnjC3cW/RQFIzjfcrAzO7ugj4 WSDzknX2HhYC2NC9Rc49+L6QO2rfwLmeJKPXi+Hh4QHJOk+Hfw6iZPCFNkR9nzPX jq/57LaeZs1X1uEUXpBzF25j6dVMv67rs1WcnsY+UrDm49lGHpZB8tPhRYqW5+sd cX2PP55SJj7Uz0v4KsDWSu/4z1oKJ7HrMRNcrCCRPjj05SN4H0bMOYKo2h3usZnC ObRHBn3Ue4dxySsmEKWZp6atTTWwj6NZhLFMhsnaBbDugUMBucsPPi2HaVbk5MJ2 RPHRA/5nlROU8D+KeLhjFOZD =jCpX -----END PGP SIGNATURE----- --nextPart5101416.LvFx2qVVIh--