program_options bad_any_cast in XCode
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; }
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
On Mon, Oct 26, 2009 at 7:48 PM, Jean-Denis Muys <jdmuys@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
On 27 Oct 2009, at 09:38, Thijs Koerselman wrote:
On Mon, Oct 26, 2009 at 7:48 PM, Jean-Denis Muys <jdmuys@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.
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
On Tue, Oct 27, 2009 at 10:59 AM, Christopher Jefferson <chris@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
participants (3)
-
Christopher Jefferson -
Jean-Denis Muys -
Thijs Koerselman