activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From mikmela <mikm...@yahoo.com>
Subject Re: Problem using ActiveMQ-CPP interfaces where std::string are used as parameters
Date Wed, 04 Jan 2012 00:05:14 GMT
quote author="tabish121@gmail.com">
On Thu, 2011-12-15 at 10:11 +0400, Ivan Pechorin wrote: 
> 2011/12/14 mikmela <[hidden email]>: 
> > I'm having a lot of issues passing std::strings into ActiveMQ-CPP
> interfaces,
 > > i.e. Connection, Session, Message and etc. 
> > Even though I'm using MS VS2010 to build both activemq-cpp dll and my 
> > application with the same version of multithreaded c-runtime dll 
> > MSVCP100.dll, MSVCR100.dll(/MD) , string object passed from the app to 
> > activevemq-cpp dll looks corrupted in debugger when I step into
> activemq-cpp
 > > code... 
> I suggest to change #define _SECURE_SCL from 1 to 0 in the following 2
> files: 
> 
> src\main\activemq\util\Config.h: 
> src\main\decaf\util\Config.h: 
> 
> This is the only change I remember required when using ActiveMQ-CPP 
> 3.4.x with MS VS2010. 
> 
> _SECURE_SCL is defined to 1 by default in VS2005 and VS2008, but this 
> was changed and VS2010 defines it to 0 by default. 
> 
> Compare the first paragraph in the following pages: 
> http://msdn.microsoft.com/en-us/library/aa985896(v=VS.90).aspx
> http://msdn.microsoft.com/en-us/library/aa985896(v=VS.100).aspx

Yes, _SECURE_SCL is the cause std:: string object corruption (Thanks Ivan!).
Microsoft introduced it to fight buffer overrun attempts. So, when this flag
is on - the size of the any STL container object (and STL string is a
container) is increased due to creation of so-called "aux object" that
stores pointer the container itself. This allows the iterators to "talk" to
their parent container to determine its current location... You can read
http://blogs.msdn.com/b/vcblog/archive/2007/08/10/the-future-of-the-c-language.aspx
for more details. The bottom line is that STL containter object size will be
different in a dll vs a client app or another dll compiled with different
value of SECURE_SCL and, as consequence,  you'll experience craches if such
container objects gets passed back and force...
 It seams that _SECURE_SCL by default (if not defined by user in project
properties) is enabled in src\main\activemq\util\Config.h and
src\main\decaf\util\Config.h. I think, it's not a such good idea -
 1) it has pretty serious perfomance implications - a)"aux object" is
dynamically allocated b)looping using iterators will be much slower as well!
 2) activemq should not impose any specific behaviour, but go with Microsoft
chosen defaults (According to Microsoft docs: in VS2010 it is disabled by
default in release mode and enabled in debug, and in VS2005 and VS2008 it is
set to 1). This way, most of the users who are not aware (or do not care) of
this Microsoft specific compilation flag and not explicitly setting it in
their app projects willl get automatically matching activemq-cpp dll.
Microsoft even recommends to have a separate configurations  dedicated to
this flag, i.e. release+_SECURE_SCL=0 and release+_SECURE_SCL=1.
 Another, approach is to always use _SECURE_SCL=0 and document it. In this
case, users that concerned about buffer overruns and ready to sacrifice
performance, will be explicitly overriding it in their environment.
 


--
View this message in context: http://activemq.2283324.n4.nabble.com/Problem-using-ActiveMQ-CPP-interfaces-where-std-string-are-used-as-parameters-tp4196115p4259238.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Mime
View raw message