[program options] access violation with _SECURE_SCL turned off
Hi, I'm using the boost 1.36 program options library on windows with msvc++2008, statically linked to my applications. In "debug mode" everything works fine, however, in "release mode" I encounter an access violation when parsing the c++ commandline passed to main() or when parsing the windows commandline with split_winmain(). Note that this happens only if and only if the preprocessor macro _SECURE_SCL gets turned off (_SECURE_SCL=0). scenario 1) Parsing the main() options, even the simple example from the tutorial, section "getting started", terminates with an access violation when calling po::store() without a usable stack trace; scenario 2) A simple call to po::split_winmain(L"\"--test\"") produces a crash. Note the use of a wide character string. The stack trace: boost::program_options::detail::utf8_codecvt_facet::do_in() boost::detail::convert<wchar_t,char,boost::_bi::bind_t<int,boost::_mfi::cmf7<int,std::codecvt<wchar_t,char,int>,int &,char const *,char const *,char const * &,wchar_t *,wchar_t *,wchar_t * &>,boost::_bi::list8<boost::_bi::value<std::codecvt<wchar_t,char,int> const *>,boost::arg<1>,boost::arg<2>,boost::arg<3>,boost::arg<4>,boost::arg<5>,boost::arg<6>,boost::arg<7>
() boost::from_8_bit() boost::from_utf8() boost::program_options::split_winmain() wmain(int argc=3407872, wchar_t * * argv=0x00000000)
Did somebody encounter this issue? Any solutions? Thanks, Klaus Triendl
Hi ! On Tuesday 17 February 2009, klaus triendl wrote:
I'm using the boost 1.36 program options library on windows with msvc++2008, statically linked to my applications.
Did you build Boost yourself ?
In "debug mode" everything works fine, however, in "release mode" I encounter an access violation when parsing the c++ commandline passed to main() or when parsing the windows commandline with split_winmain(). Note that this happens only if and only if the preprocessor macro _SECURE_SCL gets turned off (_SECURE_SCL=0).
Known "bug". Blame the compiler vendor. _SECURE_SCL=0 is ABI incompatible with _SECURE_SCL=1
Did somebody encounter this issue?
Yes, of course :-((
Any solutions?
Of course, re-compile Boost in release mode with _SECURE_SCL=0. The developer list has two or three threads about a general solution, including different name mangling. Just search the archives... Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold@ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !
Juergen Hunold schrieb:
Hi !
On Tuesday 17 February 2009, klaus triendl wrote:
I'm using the boost 1.36 program options library on windows with msvc++2008, statically linked to my applications.
Did you build Boost yourself ? [...]
Any solutions?
Of course, re-compile Boost in release mode with _SECURE_SCL=0. The developer list has two or three threads about a general solution, including different name mangling. Just search the archives...
I didn't build boost myself, until now... Thanks for your answer, that helped me a lot! Cheers, Klaus
Quoting klaus triendl <klaus@triendl.eu>:
Juergen Hunold schrieb:
Hi !
On Tuesday 17 February 2009, klaus triendl wrote:
I'm using the boost 1.36 program options library on windows with msvc++2008, statically linked to my applications.
Did you build Boost yourself ? [...]
Any solutions?
Of course, re-compile Boost in release mode with _SECURE_SCL=0. The developer list has two or three threads about a general solution, including different name mangling. Just search the archives...
I didn't build boost myself, until now... Thanks for your answer, that helped me a lot!
I naively built boost with a D_SECURE_SCL=0 on the bjam command line recently. It became the source of crashes even more confusing than those the original poster found. I believe, but never truly determined, that the define was being propagated to some but not all build targets. If you are going down this route, I recommend you investigate the feature approach of Thorsten Ottosen : http://article.gmane.org/gmane.comp.lib.boost.devel/185987 . I understand it avoids these problems but haven't yet had time to confirm that myself. Pete
Peter Bartlett schrieb:
Quoting klaus triendl <klaus@triendl.eu>:
Juergen Hunold schrieb:
Of course, re-compile Boost in release mode with _SECURE_SCL=0. The developer list has two or three threads about a general solution, including different name mangling. Just search the archives...
I didn't build boost myself, until now... Thanks for your answer, that helped me a lot!
I naively built boost with a D_SECURE_SCL=0 on the bjam command line recently. It became the source of crashes even more confusing than those the original poster found. I believe, but never truly determined, that the define was being propagated to some but not all build targets.
Hmm, I've turned the macro off on the commandline with the bjam built-in option: define=_SECURE_SCL=0
If you are going down this route, I recommend you investigate the feature approach of Thorsten Ottosen : http://article.gmane.org/gmane.comp.lib.boost.devel/185987 . I understand it avoids these problems but haven't yet had time to confirm that myself.
_CRT_NONSTDC_NO_DEPRECATE doesn't have to do anything with the *ms secure* functions but only deprecate posix named functions that have an iso c++ named variant. And as far as I understand from Stephan T Lavevej's blog (comment #2 at http://blogs.msdn.com/vcblog/archive/2007/02/26/stl-destructor-of-bugs.aspx) only _SECURE_SCL (and _HAS_ITERATOR_DEBUGGING) cause a different ABI. Klaus
participants (3)
-
Juergen Hunold -
klaus triendl -
Peter Bartlett