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--