Re: [boost] [test][range][BBv2?] issues with sub_range test

From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2007-03-04 04:20:44

"David Abrahams" <dave_at_[hidden]> wrote in message 
news:87bqjexar5.fsf_at_valverde.peloton...
>
> I'm seeing the following:
>
> 1. The test appears to do invoke undefined behavior, almost knowingly.
>   On line 103, it asks whether a singular range (so named, even) is
>   empty.  This range is made up of singular iterators, the comparison
>   of which invokes undefined behavior.  In a debug build on VC8 this
>   fires an assertion ("string iterators incompatible"). This problem
>   should be fixed.
>
>   Every major standard library now has some iterator checking.  We
>   should do debug-mode tests of our code with iterator checking on.

It tooks me some time to figure this one out. I think I could explain what 
is going on (almost). And I have a fix to avoid the dialog.

> 2. In VC8 debug builds, the test output is as follows:
>
>     Running 1 test case...
>     hello worldhello worldhello worldhello worldunknown location(0): fatal 
> error in "check_sub_range": C:\Program Files (x86)\Microsoft Visual Studio 
> 8\VC\INCLUDE\xstring(272) : Assertion failed: string iterators 
> incompatible
>
>     sub_range.cpp(103): last checkpoint
>
>     *** 1 failure detected in test suite "Master Test Suite"
>
>   Here, Boost.Test is doing its job and catching the assertion exception.

Debug version of STL supplied with this compiler relies on Crt debug 
asserts. They are intercepted by Boost.Test and successfully reported.

> 3. In VC8 release builds, the test invokes the JIT debugger.  As a
>   result, my automated release-mode tests are interfered with.
>   Nothing kills off the resulting JIT dialog, and my repeating test
>   task does not complete, which prevents the next repetition from
>   beginning.
>
>   I can't understand why that would be the case.  Doesn't Boost.Test
>   install an SEH handler?

Production version of STL supplied with this compiler doesn't do validations 
based on Crt debug asserts. But it still performs some parameter validation. 
In case if invalid parameter is detected function _invalid_parameter is 
invoked (or rather invalid_parameter_noinfo which is convenience stub that 
invoke _invalid_parameter with NULL arguments). This appears to be something 
new introduced in VC 8.0. _invalid_parameter internally checks for custom 
handler and if it's not present invokes _CRT_DEBUGGER_HOOK (defined as 
_crt_debugger_hook). Now here is where the mystery I couldn't figure out. 
_CRT_DEBUGGER_HOOK implementation is as dumb as :

int _debugger_hook_dummy;

__declspec(noinline)
void __cdecl _CRT_DEBUGGER_HOOK(int _Reserved)
{
    /* assign 0 to _debugger_hook_dummy so that the function is not folded 
in retail */
    (_Reserved);
    _debugger_hook_dummy = 0; <- crash site
}

How do we manage to cause crash/postmortem dialog inside this function and 
why Boost.Test isn't able to prevent it is unclear. Maybe some of this staff 
is treated as kind of special intrinsic by the compiler or some other magic 
is performed. It's for MS compiler guys to say.
   Anyway. What is most important is that we could actually remedy this. New 
interface _set_invalid_parameter_handler  allows me to setup custom handler

void BOOST_TEST_CALL_DECL
invalid_param_handler( wchar_t const* /* expr */, wchar_t const* /*func*/, 
const wchar_t* /*file*/, unsigned int line, uintptr_t )
{
    detail::report_error( execution_exception::user_error,
                                      "Invalid parameter detected by C 
runtime library" );
}

Once it's done no more dialog appears and above error is reported in test 
log.

This change is going to be included in next update of execution monitor.

Regards,

Gennadiy