[Boost-users] program_options bad_any_cast in XCode

[Thijs Koerselman]

Hi, 

Somehow I keep getting exceptions related to the use of strings when I compile my program in Xcode. If I use strings in my program arguments I get an bad_any_cast exception from the store() method.

If I compile the same program from the command line directly it works fine, but I can't seem to figure out what the difference is between the two build commands that is causing this behavior.

I compiled the program from the command line like this:

g++-4.2  -arch i386 -I/opt/local/include -L/opt/local/lib -lboost_program_options-mt -o waveform_manbuild main.cpp

Xcode uses the following:

CompileC build/waveform.build/Release/waveform.build/Objects-normal/i386/main.o main.cpp normal i386 c++ com.apple.compilers.gcc.4_2

cd /Users/foo/waveform

setenv LANG en_US.US-ASCII

/Developer/usr/bin/gcc-4.2 -x c++ -arch i386 -fmessage-length=0 -pipe -Wno-trigraphs -fpascal-strings -fasm-blocks -Os -mdynamic-no-pic -Wreturn-type -Wunused-variable -isysroot /Developer/SDKs/MacOSX10.5.sdk -fvisibility=hidden -fvisibility-inlines-hidden -mmacosx-version-min=10.5 -gdwarf-2 -iquote /Users/foo/waveform/build/waveform.build/Release/waveform.build/waveform-generated-files.hmap -I/Users/foo/waveform/build/waveform.build/Release/waveform.build/waveform-own-target-headers.hmap -I/Users/foo/waveform/build/waveform.build/Release/waveform.build/waveform-all-target-headers.hmap -iquote /Users/foo/waveform/build/waveform.build/Release/waveform.build/waveform-project-headers.hmap -F/Users/foo/waveform/build/Release -I/Users/foo/waveform/build/Release/include -I/opt/local/include -I/Users/foo/waveform/build/waveform.build/Release/waveform.build/DerivedSources/i386 -I/Users/foo/waveform/build/waveform.build/Release/waveform.build/DerivedSources -c /Users/foo/waveform/main.cpp -o /Users/foo/waveform/build/waveform.build/Release/waveform.build/Objects-normal/i386/main.o

The (very simple) test program is listed below. I hope someone can spot the problem. It's driving me nuts.

Cheers,

Thijs

PS: I'm using OS10.6.1 and Xcode 3.2.1

#include <iostream>

#include <boost/shared_ptr.hpp>

#include <boost/program_options.hpp>

using namespace std;

namespace po = boost::program_options;

int main (int ac, char * av[]) {

po::options_description desc("Allowed options");

desc.add_options()

   ("help", "produce help message")

   ("input-file,i", po::value< vector<string> >(), "input file")

;

po::variables_map vm;

po::store(po::parse_command_line(ac, av, desc), vm); /// << exception thrown here

po::notify(vm);    

if (vm.count("help")) {

   cout << desc << "\n";

   return 1;

}

if (vm.count("input-file")) {

   vector<string> input_files = vm["input-file"].as< vector<string> >();

vector<string>::const_iterator it = input_files.begin();

for(; it!=input_files.end(); ++it)

cout<< *it << endl;

} else {

   cout << "No input file(s).\n";

}

return 0;

}

[Jean-Denis Muys]

On Oct 26, 2009, at 16:25 , Thijs Koerselman wrote:

Hi, 

Somehow I keep getting exceptions related to the use of strings when I compile my program in Xcode. If I use strings in my program arguments I get an bad_any_cast exception from the store() method.

PS: I'm using OS10.6.1 and Xcode 3.2.1

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

Regards,

Jean-Denis

[Thijs Koerselman]

On Mon, Oct 26, 2009 at 7:48 PM, Jean-Denis Muys <jdm...@mac.com> 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.

Cheers,
Thijs
_______________________________________________
Boost-users mailing list
Boost...@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users

[Christopher Jefferson]

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

[Thijs Koerselman]

On Tue, Oct 27, 2009 at 10:59 AM, Christopher Jefferson
<ch...@bubblescope.net> wrote:

>
> 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).
>

Hi Chris,

Thanks a lot for the info. This is good to be aware of. However
_GLIBCXX_FULLY_DYNAMIC_STRING didn't fix the problem. I have narrowed
it down to the "Symbols Hidden by Default" option.
(GCC_SYMBOLS_PRIVATE_EXTERN)

Whenever this option is enabled, it causes the software to crash. It
could still have something to do with Snow Leopard, I don't know...

Cheers,
Thijs