Re: stp_exit change

["Frank Ch. Eigler" <fche at redhat dot com>]

Hi -


hunt wrote:

> This change was part of some error handling cleanup I have been meaning
> to check in for a while. [...]

What did you have in mind?


> Currently the translator emits lots of code like this:
> 	atomic_set (& session_state, STAP_SESSION_ERROR);
> 	_stp_exit ();
> and
> 	atomic_set (&session_state, STAP_SESSION_ERROR);
> 	_stp_error ("foo broke");
> and sometimes we want to exit for normal reasons (not an error)
> 	atomic_set (& session_state, STAP_SESSION_STOPPING);
> 	_stp_exit ();

Yes, from within the context of those calls, I believe they generally
make sense.

> Within the runtime, sometimes unexpected errors happen and there is
> either no return value for the function of the translator doesn't
> check it.

These both sound like bugs.

> Or maybe the runtime function just wants to print out an exact error
> message about what happened. These functions call stp_error or
> stp_exit.

Examples would be helpful.  Keep in mind the difference between
initialization-time vs probe-time errors.

> They should really set the session state variable too.

On the contrary, I would rather the runtime assume as little as
possible about translator code generation patterns.


> [...]  I recommend eliminating _stp_softerror() unless you can
> explain the difference between it and _stp_warn().

Certainly: the "ERROR" vs "WARN" "stp_vlog" channel, plus the
"WARNING" vs "ERROR" message from stpd.  The recently introduced "soft
error" concept is different from a warning, in that a script may
tolerate some limiting number of the former (and unwinds the offending
probe), and does not treat the latter any differently from a printf.


> Currently, setting session_state to either STAP_SESSION_ERROR or
> STAP_SESSION_STOPPING has the same effect; it stops probes except
> the end probe from executing. [...]

ERROR state should block "end" probes too.  An inspection of the
source suggests that it in fact does, unless something like your
stp_exit change broke it.


> Should stap exit with an error code if it is set?

Yes, that would be appropriate.  If for example the runtime's
"module_exit" function expected a return value from the
systemtap-generated shutdown code, this information could get passed
back in an orderly way.


- FChE