Boost logo

Boost :

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

"David Abrahams" <dave_at_[hidden]> wrote in message
> 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;

void __cdecl _CRT_DEBUGGER_HOOK(int _Reserved)
    /* assign 0 to _debugger_hook_dummy so that the function is not folded
in retail */
    _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

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

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



Boost list run by bdawes at, gregod at, cpdaniel at, john at