Re: Handling page faults in syscalls

> Some of the unexpected syscall faults I debugged happened because of=20=

> incorrectly set up host libraries - libGL segfaulting when trying to =
create a=20
> context, gnutls or kerberos crashing when trying to load them.

It turned out that the thing I was chasing originally was actually such =
a case (I pointed DYLD_LIBRARY_PATH at homebrew, which somehow made =
macos frameworks load a homebrew library instead of the framework's, =
which was missing some symbols it depended on, and... =
https://github.com/apple-oss-distributions/dyld/blob/3d96227e8b4626b8e6aa4=
b8b5e0765013ab510e9/dyld/Loader.cpp#L3073)
I would really have preferred if it crashed out. I think I think of it =
like, the responsibility for fixing this kind of problem is on the =
packager, and it would be much better to fail noisily so it can be =
caught earlier by the people who should be fixing it.

> On the other hand, a Windows-side STATUS_ACCESS_VIOLATION also won't =
print=20
> anything by default, there are many applications that generate a ton =
of them=20
> in their normal operation.

Do you mean the analog of EFAULT, or installing a SIGSEGV handler, or =
something else? Those are indeed "normal" and shouldn't report as a =
problem but also not what i'm talking about :p

~Theodore=