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

Status : 

  By Design<br /><br />
		The product team believes this item works according to its intended design.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.


1
1
Sign in
to vote
ID 524141 Comments
Status Closed Workarounds
Type Bug Repros 0
Opened 1/10/2010 6:52:14 AM
Access Restriction Public

Description

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
Sign in to post a comment.
Posted by Microsoft on 1/12/2010 at 3:09 PM
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
Posted by Microsoft on 1/12/2010 at 1:33 AM
Thanks for your feedback.

We are rerouting this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.

Thank you
Posted by Microsoft on 1/11/2010 at 3:53 AM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)