Boost logo

Boost :

From: Trent Nelson (tnelson_at_[hidden])
Date: 2006-04-18 14:36:51


> Hi Trent,
> can you provide me is a minimal example that reproduces this
> problem? I've tried multiline description just now, and did not
> get any assertion.
>
> I'd prefer to have a testcase for this bug before fixing it.

The following option triggered the assertion error for me every time:

desc.add_options()
    ("type,t",
     po::value<string>()->default_value("manual"),
     "startup type (\"auto\" or \"manual\") (--install only)"));

If I reduced the description length such that it fit on a single line,
the error went away for that particular option (only to crash on a
different multiline option down the track).

I was triggering the problem via '--help', which equated to 'cout <<
desc << endl;'.

I've got a pretty vanilla VC++ Express 2005 installation, I haven't done
anything out of the ordinary environment wise, which means all the new
'Standard C++ Library Security' features are enabled, so all the
_SCL_SECURE_* macros are used.

The following line:

> 395: line_end = line_begin + line_length;

Was being caught by the following macro on line 166 of 'C:\Program
Files\Microsoft Visual Studio 8\VC\include\xstring':

_Myt& __CLR_OR_THIS_CALL operator+=(difference_type _Off)
    { // increment by integer
    if (this->_Mycont != _IGNORE_MYCONT)
    {
        _SCL_SECURE_VALIDATE(this->_Mycont != NULL);
        _SCL_SECURE_VALIDATE_RANGE(
            _Myptr + _Off <= (((_Mystring *)this->_Mycont)->_Myptr() +
((_Mystring *)this->_Mycont)->_Mysize) &&
            _Myptr + _Off >= ((_Mystring *)this->_Mycont)->_Myptr());
    }
    _Myptr += _Off;
    return (*this);
    }

Which makes sense, as it's checking we don't assign past the end of our
underlying string, which is exactly what line 395 of
options_descriptions.cpp does in multiline conditions. If you can't
reproduce the assertion in VC8 with the option description I listed
above, I'd suggest putting a breakpoint on the
_SCL_SECURE_VALIDATE_RANGE() macro above. If it's not being hit (which
is what I'd expect), then something in your environment is disabling the
_SCL_SECURE* stuff.

If it is being hit, yet it's not throwing an assertion, then we have a
much more interesting situation on our hands ;-)

Regards,

        Trent.

--
http://www.onresolve.com

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk