std::string corrupt after including boost
Hello, I think the behavior of the std::string is just an example but in my application it seems to me the first stl element that is used. I have a larger project working with CLR in MC++. I included boost, because of boost::thread. Because auf the .net and CLR linking I compiled boost als shared libs and included BOOST_DYN_LINK in the preprocessor definitions. Compilation works fine. If i start the application in Debug mode i get strange behavior of my strings which results in a crash. For example an assignment like std::string test = "123"; will result in a string representation with additional malformed signs in front of the "123". I knew some behavior like this because of the Flags: #define _HAS_ITERATOR_DEBUGGING 0 #define _SECURE_SCL 0 #define _SCL_SECURE_NO_WARNINGS I usually not using them, but i have the suspicion that boost is using them and i got errors from there. Has anyone an idea what are possible solutions? Is boost introducing additional Macros that were changing the stl? Greetings Simon Adler
Hi, On Thu, Oct 28, 2010 at 9:20 PM, Simon Adler <Simon.Adler@iff.fraunhofer.de> wrote:
If i start the application in Debug mode i get strange behavior of my strings which results in a crash. For example an assignment like
I hope you are linking against the debug boost libraries. I have noticed such problems if you use boost release built libraries with debug build of your application. -dhruva
Hey,
I hope you are linking against the debug boost libraries. I have noticed such problems if you use boost release built libraries with debug build of your application.
Yes - i did. Our better "it did". Boost is linking automaticly because auf the _DEBUG Macro. During compilation with the Macro BOOST_LIB_DIAGNOSTIC set, i got the following: 1>Linking to lib file: boost_thread-vc90-mt-gd-1_44.lib 1>Linking to lib file: libboost_date_time-vc90-mt-gd-1_44.lib IMHO the gd indicates the debug version. Thanks so far Simon
1>Linking to lib file: boost_thread-vc90-mt-gd-1_44.lib 1>Linking to lib file: libboost_date_time-vc90-mt-gd-1_44.lib
Looks to me like you're mixing static and dynamic libraries there. That might be the problem.
Yes, indeed. But i thought this is okay, because for boost::date_time no dynamic library will be build by bjam - just the static once. I will take a look if i create it dynamic, but at the moment bjam is not creating the dynamic one and the auto_link is also just including the static lib. Greetings M.Sc. Simon Adler
On 28/10/10 16:50, Simon Adler wrote:
I knew some behavior like this because of the Flags:
#define _HAS_ITERATOR_DEBUGGING 0 #define _SECURE_SCL 0 #define _SCL_SECURE_NO_WARNINGS
On Windows, using Visual C++, I have experienced crashes of optimised (release) build of a program linking against program_options from binaries of Boost 1.44 downloaded from boostpro.com. Once I have removed #define _SECURE_SCL 0 from my program, craches disappeared. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org
On Windows, using Visual C++, I have experienced crashes of optimised (release) build of a program linking against program_options from binaries of Boost 1.44 downloaded from boostpro.com.
Once I have removed #define _SECURE_SCL 0 from my program, craches disappeared.
Instead, you could compile boost with -D_SECURE_SCL But of course, boost libs and your program should be compiled with the same option.
On 28/10/10 20:21, Igor R wrote:
On Windows, using Visual C++, I have experienced crashes of optimised (release) build of a program linking against program_options from binaries of Boost 1.44 downloaded from boostpro.com.
Once I have removed #define _SECURE_SCL 0 from my program, craches disappeared.
Instead, you could compile boost with -D_SECURE_SCL But of course, boost libs and your program should be compiled with the same option.
Sure thing but sometimes it's not possible to apply this solution. Second, such things should be documented somewhere. Perhaps I've missed it. However, thanks to this self-resolved bug report, I was able to sort it out. https://svn.boost.org/trac/boost/ticket/967 Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org
Once I have removed #define _SECURE_SCL 0 from my program, craches disappeared.
I remember having the same issue with program_options a while ago. But why does that happen? What does program_option do that makes it so fragile without _SECURE_SCL? Other libs seems to work just fine. Regards, Christian
The std iterators or containers are different. I forget which option does what to them, but I have two such things in my project too. If stl items are passed between files compiled with different options, then boom.
-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users- bounces@lists.boost.org] On Behalf Of Christian Henning Sent: Thursday, October 28, 2010 6:04 PM To: boost-users@lists.boost.org Subject: Re: [Boost-users] std::string corrupt after including boost
Once I have removed #define _SECURE_SCL 0 from my program, craches disappeared.
I remember having the same issue with program_options a while ago. But why does that happen? What does program_option do that makes it so fragile without _SECURE_SCL?
Other libs seems to work just fine.
Regards, Christian _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.
On 29/10/10 00:28, John Dlugosz wrote:
The std iterators or containers are different. I forget which option does what to them, but I have two such things in my project too. If stl items are passed between files compiled with different options, then boom.
Indeed, it's likely related to the problems explained here: Allocating and freeing memory across module boundaries http://blogs.msdn.com/oldnewthing/archive/2006/09/15/755966.aspx Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org
Indeed, it's likely related to the problems explained here:
Allocating and freeing memory across module boundaries
http://blogs.msdn.com/oldnewthing/archive/2006/09/15/755966.aspx
I've dealt with that by setting up projects to use the DLL version of the run-time library. Even before that was the default in Visual Studio, it has this big advantage. It's like virtual inheritance in C++: all DLLs that link to the DLL RTL will refer to the _same_ copy of the RTL. With Visual Studio 2008 (maybe it started earlier, I'm not sure) there is a new wrinkle: different DLLs compiled with the same version of the compiler can refer to different patch versions of the RTL. So, either make sure all DLLs are compiled with the default options (link to original RTL version regardless of newer ones available) or compile all with _BIND_TO_CURRENT_VCLIBS_VERSION=1 which binds to the latest version available at compile-time, with the same latest one seen at compile-time for each module. It's crazy really. Win32 addressed this issue by having a process global heap. If all the copies of the RTL used that, they would interoperate just fine. But the start-up code goes out of its way to ignore it and create its own heap instead, so each copy of the RTL is its own memory pool. The problems reported by the OP have, if I read and remember correctly, with conditional compilation in the standard library headers. Specifically, if debug builds are compiled with _HAS_ITERATOR_DEBUGGING=0 then all DLLs must be built that way. Since the conditional compilation this triggers is in the STL iterators, than it's only a problem if iterators are involved in the calls or member accesses etc. across the DLL boundaries. Likewise _SECURE_SCL=0 will change the layout of the STL container classes. string and wstring are compatible across, since special support is included to make that polymorphic at run-time and allow those instantiations to live inside the single DLL. But other containers will change their size, messing up other structures that contain them, and calls using them will refer to wrong addresses. So, if STL is involved, the DLLs must have this option set the same way. Personally, I solved this with Boost by remaking the Visual Studio project files for the (few) Boost DLLs I needed, and not using Jam at all. I specifically recommend using a "property sheet" in Visual Studio to record these build conventions, and refer to the same property sheet in all the projects of your application suite. --John TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.
On Fri, Oct 29, 2010 at 9:56 AM, John Dlugosz <JDlugosz@tradestation.com> wrote:
Indeed, it's likely related to the problems explained here:
Allocating and freeing memory across module boundaries
http://blogs.msdn.com/oldnewthing/archive/2006/09/15/755966.aspx
I've dealt with that by setting up projects to use the DLL version of the run-time library. Even before that was the default in Visual Studio, it has this big advantage. It's like virtual inheritance in C++: all DLLs that link to the DLL RTL will refer to the _same_ copy of the RTL.
With Visual Studio 2008 (maybe it started earlier, I'm not sure) there is a new wrinkle: different DLLs compiled with the same version of the compiler can refer to different patch versions of the RTL. So, either make sure all DLLs are compiled with the default options (link to original RTL version regardless of newer ones available) or compile all with _BIND_TO_CURRENT_VCLIBS_VERSION=1 which binds to the latest version available at compile-time, with the same latest one seen at compile-time for each module.
It's crazy really. Win32 addressed this issue by having a process global heap. If all the copies of the RTL used that, they would interoperate just fine. But the start-up code goes out of its way to ignore it and create its own heap instead, so each copy of the RTL is its own memory pool.
The problems reported by the OP have, if I read and remember correctly, with conditional compilation in the standard library headers. Specifically, if debug builds are compiled with _HAS_ITERATOR_DEBUGGING=0 then all DLLs must be built that way. Since the conditional compilation this triggers is in the STL iterators, than it's only a problem if iterators are involved in the calls or member accesses etc. across the DLL boundaries.
Likewise _SECURE_SCL=0 will change the layout of the STL container classes. string and wstring are compatible across, since special support is included to make that polymorphic at run-time and allow those instantiations to live inside the single DLL. But other containers will change their size, messing up other structures that contain them, and calls using them will refer to wrong addresses. So, if STL is involved, the DLLs must have this option set the same way.
Personally, I solved this with Boost by remaking the Visual Studio project files for the (few) Boost DLLs I needed, and not using Jam at all. I specifically recommend using a "property sheet" in Visual Studio to record these build conventions, and refer to the same property sheet in all the projects of your application suite.
I just build boost like this: bjam --build-type=complete --toolset=msvc-8.0 --without-mpi --prefix=R:/SDKs/boost/built_head --build-dir=R:/SDKs/boost/build_head define=_CRT_NONSTDC_NO_DEPRECATE define=_CRT_SECURE_NO_DEPRECATE define=_CRT_SECURE_NO_WARNINGS define=_SECURE_SCL=0 define=_SCL_SECURE_NO_DEPRECATE define=_HAS_ITERATOR_DEBUGGING=0 install>..\build-HEAD.log 2>&1 Along with the appropriate macros in my own projects, I have no issues, and in some cases some tremendous speed benefits (iterator debugging slowed some of my apps down from running in milliseconds to running in 12 seconds, screw that!).
Once I have removed #define _SECURE_SCL 0 from my program, craches disappeared.
I remember having the same issue with program_options a while ago. But why does that happen? What does program_option do that makes it so fragile without _SECURE_SCL?
Other libs seems to work just fine.
I believe that code compiled with that option is binary incompatible with code compiled without it - so if you link with a library that depends on a std lib symbol that changes it's interface based on that define, then you'd better be sure to use the same settings as that library (or else recompile the lib). HTH, John.
Hello, yes - you have solved my Problem - boost works. I just want do describe what i had to do, so new Users to boost may not be furstrated by a thread that is just finished with "problem solved", but not how .-) First i think the _SECURE_SCL Problem was the main problem. I solved this calling ./bjam link=shared cxxflags=-D_SECURE_SCL However, i was a little wrong. The Module time_date was build as dll, but it was included as static during compilation. This was, because I had declared BOOST_DYN_LINK and not BOOST_ALL_DYN_LINK in my preprozessor definitions. Now i can compile and execute my programm successfully. M.Sc. Simon Adler ------------------------------------------------------------------------------ Fraunhofer Institut für Fabrikbetrieb und -automatisierung IFF Virtual Development and Training Centre VDTC Joseph-von-Fraunhofer-Strasse 1 39106 Magdeburg Germany wissenschaftlcher Mitarbeiter (VP) Telefon +49 391/40 90-776 Internet: www.iff.fraunhofer.de boost-users-bounces@lists.boost.org schrieb am 29.10.2010 10:42:28:
Von: John Maddock <boost.regex@virgin.net> An: <boost-users@lists.boost.org> Datum: 29.10.2010 10:45 Betreff: Re: [Boost-users] std::string corrupt after including boost Gesendet von: boost-users-bounces@lists.boost.org
Once I have removed #define _SECURE_SCL 0 from my program, craches disappeared.
I remember having the same issue with program_options a while ago. But why does that happen? What does program_option do that makes it so fragile without _SECURE_SCL?
Other libs seems to work just fine.
I believe that code compiled with that option is binary incompatible with code compiled without it - so if you link with a library that depends on a std lib symbol that changes it's interface based on that define, then you'd better be sure to use the same settings as that library (or else recompile the lib).
HTH, John.
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
participants (9)
-
Christian Henning -
dhruva -
Eric J. Holtman -
Igor R -
John Dlugosz -
John Maddock -
Mateusz Loskot -
OvermindDL1 -
Simon Adler