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

From: carlos pizano (carlospizano_at_[hidden])
Date: 2003-09-22 23:31:19

> In the article.  Did you read it?  I hope I don't need to provide the
> link again.

I did. It is good info. IMHO you should state there that your technique
does not need /EHa. People like me tend to believe their compilers/books
too much.

>> I hope I can get the attention of the maintainer of boost.test and
>> that he/she feels like thinking.
> ...but there's no need to patronize.

I did not meant to come across like that. Sorry.

Now that I get that your technique is all about JIT Debugging, the
problem is that there are two possible translators in execution_monitor:

void
ms_se_trans_func( unsigned int id, _EXCEPTION_POINTERS* /* exps */ )
{
    throw ms_se_exception( id );
}

void
ms_se_forward_func( unsigned int /* id */, _EXCEPTION_POINTERS* /* exps
*/ )
{
    throw;
}

Which one is used depends on the bool catch_system_errors, if true the
first one is used. That first one is not about JIT debugging because
there is an enclosing catch block:

int execution_monitor::execute( bool catch_system_errors, int timeout )
{
        
        ..... lot of code here removed ..... 
        ..... Eventually calls the user code inside a try{} block

    catch( std::exception const& ex )
      { detail::report_error(cpp_exception_error, ..); }

    catch( detail::ms_se_exception const& ex )
      { detail::report_ms_se_error( ex.id() ); }

    catch( execution_exception const& ) 
        { throw; }

    catch( ... )
      { detail::report_error(cpp_exception_error, "unknown type" ); }

}

for reference:

static void report_error(error_code ec, c_string_literal msg1,
c_string_literal msg2 )
{
    static char buf[REPORT_ERROR_BUFFER_SIZE];
    buf[0] = '\0';
    std::strncat( buf, msg1, sizeof(buf)-1 );
    std::strncat( buf, msg2, sizeof(buf)-1-std::strlen(buf) );
    throw execution_exception( ec, buf );
}

See my problem? the code expects to catch ms_se_exception. Looks like an
error under /EHs.

Also my confusion was from thinking that your technique was paired with
the last catch(...) when is not.

Maybe I am too dense but I see this code trying to do both JIT debugging
and unwind/report at the same time... I just don't get it.

Maybe Gennadiy can help me here.

CPU

-----Original Message-----
From: boost-bounces_at_[hidden]
[mailto:boost-bounces_at_[hidden]] On Behalf Of David Abrahams
Sent: Monday, September 22, 2003 6:57 AM
To: boost_at_[hidden]
Subject: [boost] Re: boost::execution_monitor impl under windows

"carlos pizano" <carlospizano_at_[hidden]> writes:

>> URL please.
>
> Here:
> http://aspn.activestate.com/ASPN/Mail/Message/boost/1811713
>
>> What interaction?
>
> See URL above and/or Robbins book chapter 13
>
>
>>> I don't think so. Well, it can fail. 
>>It only fails under restricted circumstances, which are documented.
>
> That is the *interaction* I am talking about: it can fail. 
>
>> which are documented.
>
> Where is this documentation? In boost.test ? in the source?

In the article.  Did you read it?  I hope I don't need to provide the
link again.

> I would like to learn where it can and cannot work. My current
> understanding is that it works when the compiler does not optimize too
> much :)

No, it works unless the SEH is generated inside a catch block.  As
documented.

>> I think you are seriously missing my point.  This is not a substitute
>> for my technique because it causes unwinding and recovery instead of
>> going immediately to JIT debugging.
>
> a) I guess I am. You mentioned earlier that you don't know what
> execution_monitor is doing, now is a good time to check it out because
> we are not talking about your technique in the vacuum. 

I don't really care what it's currently doing.  I'm saying that if
it's using my technique /EHa doesn't matter and if it's not using my
technique it probably should be.

> b) My proposal can do the same thing(s) as your technique for
> execution_monitor. Mine causes unwinding and yours not? You lost me
> there. Please explain. 
>
> c) causes recovery? I never said recovery... where do you get that
from
> my pseudo code?

OK, I mistoook the __except clause for a __catch.  However, your code
differs from mine in one important way: if any inner code happens to
use 

    catch(...) { ...  throw; } 

(which is still legitimate code on most platforms) it will still
produce unwinding.

>> Interesting things are counter-productive at this point.  
>
> Okeey.. How should I read that?

I mean to say that the actions after an SEH should be very simple and
lead almost immediately to shutdown.

>> "Invoke the debugger" is the right thing to do for developers, and
>> "report failure and terminate" is the right thing to do for
>> testers.
>
> No problem there. Remember that we have other classes derived from
> execution_monitor where behavior is specialized for production or
> testing.

Not sure how that's relevant... but you can stick any code you like
before the "throw;" in my SE translator.

>>> Think about it.
>> No thanks! ;-)
>
> I know, thinking sometimes is difficult. 

Yes, usually, in fact...

> I hope I can get the attention of the maintainer of boost.test and
> that he/she feels like thinking.

...but there's no need to patronize.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com
_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost