On 09/03/2018 12:46 AM, H. S. Teoh wrote:
On Sun, Sep 02, 2018 at 09:33:36PM -0700, H. S. Teoh wrote:
[...]
The reason I picked memory corruption is because it's a good
illustration of how badly things can go wrong when code that is known to
have programming bugs continue running unchecked.
[...]
P.S. And memory corruption is also a good illustration of how a logic
error in one part of the program can cause another completely unrelated
part of the program to malfunction. The corruption could have happened
in your network stack, but it overwrites memory used by your GPU code.
You cannot simply assume that just because the network module has
nothing to do with the GPU module, that a GPU code assertion failure
cannot be caused by a memory corruption in the network module.
Therefore, you also cannot assume that an assertion in the GPU code can
be safely ignored, because by definition, the program's logic is flawed,
and so any assumptions you may have made about it may no longer be true,
and blindly continuing to run the code means the possibility of actually
executing a remote exploit instead of the GPU code you thought you were
about to execute.
Isn't that assuming the parts aren't @safe? ;)
Anything less is unsafe, because being
in an invalid state means you cannot predict what the program will do
when you try to recover it. Your state graph may look nothing like what
you thought it should look like, so an action that you thought would
bring the program into a known state may in fact bring it into a
different, unknown state, which can exhibit any arbitrary behaviour.
You mean attempting to doing things, like say, generate a stack trace or
format/display the name of the Error class and a diagnostic message? ;)
Not to say it's all-or-nothing of course, but suppose it IS memory
corruption and trying to continue WILL cause some bigger problem like
arbitrary code execution. In that case, won't the standard Error class
stuff still just trigger that bigger problem, anyway?
