Re: [Boost-users] program_options bad_any_cast in XCode

Subject: Re: [Boost-users] program_options bad_any_cast in XCode
From: Christopher Jefferson (chris_at_[hidden])
Date: 2009-10-27 05:59:39

On 27 Oct 2009, at 09:38, Thijs Koerselman wrote:

> On Mon, Oct 26, 2009 at 7:48 PM, Jean-Denis Muys <jdmuys_at_[hidden]>  
> wrote:
>>
>> I have been bitten by the following item in XCode 3.2.1 release  
>> notes:
>>
>> The default gcc 4.2 compiler is not compatible with the Standard C+ 
>> + Library Debug Mode. C++ programs compiled with Xcode 3.2 may not  
>> work in the Debug configuration. To fix this, set the Compiler  
>> Version to 4.0, or edit the Debug configuration’s Preprocessor  
>> Macros and remove the entries:
>>
>> _GLIBCXX_DEBUG=1 _GLIBCXX_DEBUG_PEDANTIC=1
>>
>> I would say the likelihood this is happening to you is rather high.
>> Please note that another possible workaround, beside the ones  
>> listed above, is to set the base SDK to 10.5
>
> I've tried both gcc4.2 and 4.0 as well as 10.5 and 10.6 as base SDK. I
> switched to XCode 3.2.1 as a last resort because I was using 3.2.0
> before that which had the same issues.
>
> I just discovered that if I remove the  _GLIBCXX_DEBUG=1
> _GLIBCXX_DEBUG_PEDANTIC=1 for the debug configuration the program
> works. Searching for the difference between debug (which is working)
> and release (which is crashing), I first turned off optimization, but
> without luck. I then narrowed it down to "Fix and Continue" or
> GCC_ENABLE_FIX_AND_CONTINUE.
>
> If this setting is disabled, the code crashes. Looking at the details
> of this settings it says: Activating this setting will disable the
> settings "Symbols Hidden by Default" and "Generate Position-Dependent
> Code". Is any of these two settings the possible culprit?
>
> If I don't use fix and continue, store() throws and exception like  
> this:
>
> #8	0x00004f6b in boost::throw_exception<boost::bad_any_cast> at
> throw_exception.hpp:64
> #9	0x00007c39 in boost::any_cast<std::string> at any.hpp:195
> #10	0x00008673 in boost::program_options::validate<std::string, char>
> at value_semantic.hpp:149
> #11	0x0000884e in
> boost::program_options::typed_value<std::vector<std::string,
> std::allocator<std::string> >, char>::xparse at value_semantic.hpp:169
> #12	0x000e17ae in
> boost::program_options::value_semantic_codecvt_helper<char>::parse
> #13	0x000deba7 in boost::program_options::store
> #14	0x00001ae2 in main at main.cpp:42
>
> At least I can now compile and run my program, but it would be nice to
> know what the actual problem is here.

I haven't investigated this exact problem, but I suspect it isn't  
related to boost, but due to a general problem in Snow Leopard (which  
I guess you are using), where Apple has broken std::string (or at  
least, made it very fragile).

The problem is described here: http://www.cocoabuilder.com/archive/message/cocoa/2009/9/17/245285 
. I hit it when trying to compile g++ from source. Basically the  
binary of the standard library was built with  
_GLIBCXX_FULLY_DYNAMIC_STRING, but the headers are not. That option  
effects mainly an optimisation to do with empty strings, and leads to  
memory crashes if it is defined in some places and not others.

The code just about works, due to a number of 'extern' templates in  
the headers. However, a number of options, including -D_GLIBCXX_DEBUG  
and -D_GBLIBCXX_PARALLEL, remove this extern and cause a horrible clash.

An easy way to test if this is your problem is to add - 
D_GLIBCXX_FULLY_DYNAMIC_STRING to your command line and see if it  
fixes your problems (I suspect it will).

This is one time when Apple's secretive ways are very annoying, I've  
reported this to them as a bug, but had no reply yet as to if they  
intend to fix it in a sensible way, of if I should work around it  
myself.

Chris