RE: [boost] Re: boost::execution_monitor impl under windows

From: Rozental, Gennadiy (gennadiy.rozental_at_[hidden])
Date: 2003-09-26 10:37:12

> "Gennadiy Rozental" <gennadiy.rozental_at_[hidden]> writes:
> >  In fact there are series of SEH that look pretty 
> "recoverable". Most 
> > of them are related to some king of arithmetic errors (float or 
> > integer). If user willing to take the risk of wrong result it seems 
> > perfectly legit to continue.
> 
> Careful.  That can only work if you have continuation-model 
> EH.  If you have termination-model EH (like in C++), there 
> will be trouble if the arithmetic error occurs in a region 
> that's expected to be non-throwing.  Furthermore, because of 
> FP pipelining, FP exceptions may occur some random number of 
> instructions after the actual error, so controlling where the 
> "recoverable" exceptions arise is well-nigh impossible.

  When I say "recoverable" I mean that test program could skip current test
case and proceed with next one - IOW it should not affect further testing. I
admit the possibility of some missing destructors, but this is the user call
- after all in test program it may not be that major crime. 
  And let me state again: I agree that In production code any SE should be
considered nonrecoverable and treated respectively.

[snip]

> > After all when you are running a 
> > regression test suite, you don't really bother was what an actual 
> > point where it crashed,
> 
> I disagree.  The next thing that usually happens after a 
> crash during testing is debugging. 

That's the key. Once you switched from scenario 2 to scenario 2 you do want
to know where it crashed. In Boost.Test term it means that you pass extra
argument --catsh_system_error=no.
 
[snip]

> > 9th from 10 test cases. Why should we throw out the work done?
> 
> Who said anything about throwing out the work done?  I was 
> just saying you probably shouldn't try to do any *more* work.

I would be difficult and inconvenient to access reporting mechanisms from
inside SE handler. Instead I convert it to special fatal error notification.
I catch it on Monitor level and invoke shutdown routines. It does may skip
some destructors or we could get unlucky and crush again. But this way
Boost.Test code much cleaner. Also I think that many NT compilers may
produce some kind of window with error message - that would be major
inconvenience for regression tester.
 
> > For testing this is not true - we are not going to invoke  the debugger.
> 
> But hopefully you're going to report *some* useful 
> information about the crash, and unwinding can easily 
> interfere with your ability to do so.

Why?

> > For production code it probably also preferable to generate 
> core vs. 
> > try to invoke shutdown procedures.
> 
> Often it's better to do some shutdown (like saving an 
> intermediate work recovery file) before dumping core.
> 
> > But this is not definite. User may have external knowledge 
> about the 
> > code being monitored, that allows one make best decision that fits. 
> > More over in many c ases even if one wants to generate core, some 
> > release code may still needs to be invoked. For example to 
> free used 
> > resources. I was several times hit by the application that does not 
> > remove some kind of lock when crashes and does not restart 
> until I go 
> > in some remote location and clean some files.
> 
> There are better ways to handle that than by doing it with 
> unwinding.

I do NOT propose to employ unwinding in production code. More over we seemed
to be in total agreement.
In some rare case user may be willing to do so - and I do not see a reason
to prevent it.

> You have not done any of the required legwork to make sure 
> that you actually have recoverability from SEHes, and you 
> can't -- it requires explicit and painstaking cooperation 
> from the program dropped into your testing framework.

I talk under assumption that in majority of the cases test cases in unit
test program more or less independent. That mean that if you got "integer
divide by zero" error in one test case you could fail that one and continue.

> > In most cases I am willing to take the risk and resort to 
> Boost.Test 
> > shutdown procedures, that will show results report.
> 
> There's no reason you can't show the results report without unwinding.

I may look into possibility to do so. But I afraid it may broke
encapsulation. IOW will be inconvenient.

> > Though I one wants second option should also be available.
> 
> You seem convinced that trying to recover from SEHes is a 
> reasonable default behavior.

For production program I do not argue the possibility to recover. In test
program in some rare cases seemed pretty innocent. Also I argue the way I
perform reporting even if are not going to continue.

> > P.S.  I want to emphasize that this discussion should also be 
> > applicable to fatal signals caught in signaling capable environment.
> 
> I don't believe so.  Signals are truly asynchronous and can 
> occur during nothrow regions such as destructors.  Nothing 
> warrants unwinding at that point.

What about SIGALRM? I use one to timeout test case.
And again what will happened if I got SIGFPE while in destructor and employ
unwinding?

Gennadiy.