Half-baked thought: Out-of-process asserts

[H. S. Teoh]

On Mon, Sep 03, 2018 at 11:39:04PM -0400, Nick Sabalausky (Abscissa) via Digitalmars-d wrote:
> It seems pretty well established around here that:
> 
> 1. Doing anything after a process has entered an unknown state is
> dangerous, and the more activity, the more danger [...]
> 
> 2. For practical reasons, some things currently still need to be done
> in the process which is already in an invalid state: Evaluating the
> assert in the first place, generating a diagnostic message, generating
> the stack trace, etc...
> 
> What if a compiler (or library, standard tool, etc...) could
> automatically add an additional separate OS process to the program (or
> perhaps some other form of encapsulation that would isolate it from
> any corruption in the main process), [...]
[...]

This is an interesting idea.  At least on Posix systems, this monitor
process could attach to the main process via the debugging mechanism
(the same way utilities like strace or gdb can attach to an existing
process), and use SIGSTOP to suspend the process when a problem is
detected, extract stacktraces and other info, and use SIGKILL / SIGABRT
/ etc. to terminate the program.

I've seen similar this actually implemented manually in the form of a
set of cooperating processes, though this is the first time I've heard
of the compiler automatically generating this sort of code.

Possible wrinkles in the works are debugging privileges, which the
monitor process may not have, which would limit the kind of information
you could monitor / extract from the terminated process.  It's probably
possible, if coredumps are turned on, to extract the stacktrace from the
coredump file directly, so you wouldn't need debugging privileges.  But
you wouldn't be able to monitor the process independently without
explicit cooperation unless you had debug privileges (like reading the
process's memory).  Still, even an explicit scheme could be useful,
e.g., a pipe of some sort that the main process writes status codes to,
and the monitor process reads from it and suspends / terminates the main
process if anything looks out-of-place.  But this may be much harder to
automatically generate code for.


T

-- 
Let's call it an accidental feature. -- Larry Wall