Serious BUG when using _SECURE_SCL=0 C++

Serious BUG when using _SECURE_SCL=0 C++ by _______

Closed

as By Design Help for as By Design

Type:	Bug
ID:	524141
Opened:	1/10/2010 6:52:14 AM
Access Restriction:	Public

Workaround(s)

view

User(s) can reproduce this bug

http://social.msdn.microsoft.com/Forums/en-US/vclanguage/thread/c4eb85ce-1c4d-4b2e-a94d-d41cf6eee752

I have the following code, when compiled in debug or release mode
it works fine. When I add the _SECURE_SCL=0 however, its crashes
with the following call-stack:

**************************************************
example.exe!_crt_debugger_hook(int _Reserved=3619112) Line 65 C
example.exe!_invalid_parameter(const wchar_t * pszExpression=0x00000000, const wchar_t * pszFunction=0x00000000, const wchar_t * pszFile=0x00000000, unsigned int nLine=0, unsigned int pReserved=0) Line 112 + 0x7 bytes C++
example.exe!_invalid_parameter_noinfo() Line 125 + 0xc bytes C++
example.exe!boost::match_results<std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char> >,std::allocator<boost::sub_match<std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char> > > > >::set_size() + 0x5b bytes C++
example.exe!boost::re_detail::perl_matcher<std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char> >,std::allocator<boost::sub_match<std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char> > > >,boost::regex_traits<char,boost::w32_regex_traits<char> > >::find_imp() + 0xc9 bytes C++
**************************************************

I've successfully been able to run the code in release using vc8.0, intel v11 (/o2)
and gcc 4.4 (O2 and O3). I'm not sure where the trouble lies, but I think its got
to do with a VS patch done within the last month, because this particular bit of
code was working last time I checked (late nov '09).

Other info:

VS2008 Team, SP1

Command Line: /O2 /Oi /Ot /GL /D "WIN32" /D "NDEBUG" /D "_CONSOLE" /D "NOMINMAX" /D "_SCL_SECURE_NO_WARNINGS" /D "_SECURE_SCL=0" /D "_UNICODE" /D "UNICODE" /FD /EHsc /MT /Gy /Fo"Release\\" /Fd"Release\vc90.pdb" /W4 /nologo /c /Zi /TP /errorReport:prompt

Details (expand)

English

Visual Studio 2008 SP1

Windows XP

English (US)

Code snippet:

#include <iostream>
#include <string>
#include <boost/regex.hpp>

int main()
{
using namespace boost;
std::string s = "(1)(23)(456)(7890)";
regex expr("\\(.*?\\)");
sregex_iterator itr(s.begin(),s.end(),expr);
sregex_iterator it_end;
std::size_t match_count = 0;
while (it_end != itr)
{
++itr;
++match_count;
}
std::cout << "Match count: " << match_count << std::endl;
return 0;
}

http://social.msdn.microsoft.com/Forums/en-US/vclanguage/thread/c4eb85ce-1c4d-4b2e-a94d-d41cf6eee752

A crash occurs.

http://social.msdn.microsoft.com/Forums/en-US/vclanguage/thread/c4eb85ce-1c4d-4b2e-a94d-d41cf6eee752

Not to crash, I've successfully been able to run the code in release using
vc8.0, intel v11 (/o2) and gcc 4.4 (O2 and O3). I'm not sure where the
trouble lies, but I think its got to do with a VS patch done within the last
month, because this particular bit of code was working last time I checked
(late nov '09).

http://social.msdn.microsoft.com/Forums/en-US/vclanguage/thread/c4eb85ce-1c4d-4b2e-a94d-d41cf6eee752

Hi,

Thanks for reporting this issue. I've resolved it By Design because this is caused by _SECURE_SCL mismatch.

When changing _SECURE_SCL from its default setting, certain rules need to be followed. These rules are logical consequences of the fact that _SECURE_SCL changes the representations (including the sizes) of STL objects.

The first rule is that _SECURE_SCL must be consistently set throughout each translation unit (a translation unit is a source file and all of its included header files, which is compiled into an object file). That is, _SECURE_SCL can't be changed in the middle of a translation unit. The easiest way to follow this rule is by defining _SECURE_SCL on the command line (or in your project settings) instead of in source files/header files. (This rule is being followed by your case; I mention it for completeness.)

The second rule is that _SECURE_SCL must be consistently set in all of the object files that are linked into a single binary (EXE or DLL). Mismatch will be not detected by the VC8/VC9 linker, and will cause incomprehensible crashes. (In technical terms, _SECURE_SCL mismatch is a One Definition Rule violation.)

The second rule applies to static libraries (which are simply packages of object files).

The third rule is that _SECURE_SCL must be consistently set among binaries (EXEs/DLLs) that pass STL objects to each other. If a DLL has a C or COM interface, nobody can tell what _SECURE_SCL setting it was built with, but if the DLL uses STL objects in its interface, then the mismatch rule applies.

This means that when using Boost (either statically linked or dynamically linked), you must recompile it with _SECURE_SCL defined the same way as in your own code.

VC10's linker has been enhanced to detect violations of the second rule (and of the third rule when import libs are used, according to my understanding - if a DLL is loaded through LoadLibrary() then there's no way to detect mismatch).

Additionally, _SECURE_SCL defaults to 0 in release mode in VC10.

If you have any further questions, feel free to E-mail me at stl@microsoft.com .

Stephan T. Lavavej
Visual C++ Libraries Developer