www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Half-baked thought: Out-of-process asserts

reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
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 (Note also, the 
transition to an unknown state actually occurs *before* any assert which 
is intended to detect it.)

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), and it is in this separate process 
where the compiler would insert the code responsible for one or more of 
the following:

- Generating stack traces upon detection of an assert failure (or 
bounds-check violation, or out-of-memory, etc).
- Formatting the custom assert failure string.
- Anything additional data gathering? Like a core dump?
- Display/log/report these diagnostics.
- Optionally restart the main process, depending on the type of program.
- Maybe even *performing* the assert/etc. checks by closely monitoring 
the main process and being aware of its state and memory layout.

The idea of course being to even further minimizing the work the errant 
process needs to do.

Discussion questions:
- What would be the feasibility of the various parts of this?
- Would this be an improvement or not?
- What would be the downsides, and how serious would they be?
Sep 03 2018
next sibling parent Neia Neutuladh <neia ikeran.org> writes:
On Tuesday, 4 September 2018 at 03:39:04 UTC, Nick Sabalausky 
(Abscissa) wrote:
 Discussion questions:
 - What would be the feasibility of the various parts of this?
You'd need to interrupt the process. You'd need a parent process that detects the interrupt. Then you'd need to use the debugger API to attach to the child process and get the relevant data. Annoying to write, but it should work, assuming the child process didn't install a signal handler to handle SIGABRT. You could simply call SIGABRT and create a core dump, but that can be costly on a system where your application might use multiple gigabytes of RAM.
 - What would be the downsides, and how serious would they be?
It's extra complexity. It means you must run in a multiprocessing environment (which is almost, but not quite, a trivial requirement). If you're running as a user without debugger privileges, you're horked; you aren't getting an error message at all. The benefit is that you can safely do more elaborate logging when more of your runtime and base frameworks are in an invalid state. I think most people are happy to live dangerously or to go with simpler logging.
Sep 03 2018
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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
Sep 04 2018
prev sibling parent Arjan <arjan ask.me.to> writes:
On Tuesday, 4 September 2018 at 03:39:04 UTC, Nick Sabalausky 
(Abscissa) 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 (Note 
 also, the transition to an unknown state actually occurs 
 *before* any assert which is intended to detect it.)

 [...]
Reminds me of google breakpad: https://chromium.googlesource.com/breakpad/breakpad/+/master/docs/
Sep 04 2018