[program_options] Multiple segfaults

I'm starting to use boost::program_options and am not having much luck:
-home-> ./options_test Got debug value default Got option default Segmentation fault (core dumped)
-home-> ./options_test --help free(): invalid pointer 0x8fb06f8! free(): invalid pointer 0x8fafcd0! Got debug value default Got option default Segmentation fault (core dumped)
-home-> ./options_test --help --debug io free(): invalid pointer 0x8a83ec0! free(): invalid pointer 0x8a83ed0! free(): invalid pointer 0x8a83ec8! free(): invalid pointer 0x8a84a38! Segmentation fault (core dumped)
At first I thought it might be a problem with the -mt version as my larger application is threaded. But I compiled the testcase attached below as a single-threaded application and it still fails in the same ways. I'm not sure if my use of vector<string> is correct. The documentation is confusing on this point. In http://boost.sourceforge.net/doc/html/program_options/overview.html one example with the "email" option uses multitoken with "string" and another uses "combining" with "vector<string>." Is it not possible to have a combining and multitoken option value? What's the correct value type to use if I want the multiple tokens for the "debug" option to appear as separate items in a vector (or other sequence)? Or do I have to stuff them in a single string and manually parse them out later? -Dave ------------------------ #include <boost/bind.hpp> #include <boost/program_options.hpp> //#include <boost/filesystem/operations.hpp> //#include <boost/filesystem/fstream.hpp> #include <vector> #include <string> #include <iostream> #include <algorithm> #include <iterator> std::ostream &operator<<(std::ostream &out, const std::vector<std::string> &value); std::ostream &operator<<(std::ostream &out, const std::vector<std::string> &value) { std::copy(value.begin(), value.end(), std::ostream_iterator<std::string>(out, " ")); return(out); } namespace test { namespace opt = boost::program_options; //namespace fs = boost::filesystem; static void validate_debug_options(const opt::options_description &debug, const std::vector<std::string> &value) { std::cout << "Got debug value " << value << std::endl; for(std::vector<std::string>::const_iterator i = value.begin(); i != value.end(); ++i) { std::cout << "Got option " << *i << std::endl; } } void process_options(int argc, char **argv) { opt::options_description help("Help options"); opt::options_description debug("Debug options"); opt::options_description cmdline_options; opt::options_description cfgfile_options; help.add_options() ("help", "This help message"); typedef std::vector<std::string> option_vector; option_vector default_debug_flags; default_debug_flags.push_back("default"); debug.add_options() ("debug,d", opt::value<std::vector<std::string> >()-> // For some reason can't find operator<< declared above default_value(default_debug_flags, "default")-> composing()-> multitoken()-> notifier(boost::bind(validate_debug_options, boost::ref(debug), _1)), "Debug flags:\n\n" " foo: \tDo something\n" " bar: \tDo something else\n" " baz: \tDon't do anything\n"); cmdline_options.add(help).add(debug); cfgfile_options.add(debug); opt::variables_map vm; opt::store(opt::parse_command_line(argc, argv, cmdline_options), vm); // fs::ifstream config_file("./opt.cfg"); // if (config_file) { // opt::store(opt::parse_config_file(config_file, cfgfile_options), vm); // } opt::notify(vm); } } int main(int argc, char **argv) { test::process_options(argc, argv); return(0); }

Hi, I am new to Boost library. I wonder if the Boost functional library is a sub-set of the Boost bind library? http://www.boost.org/libs/functional/ http://www.boost.org/libs/bind If now, what functionality that functional library provides that bind library does not? Thank you. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

yinglcs2@yahoo.com wrote:
Hi,
I am new to Boost library. I wonder if the Boost functional library is a sub-set of the Boost bind library?
http://www.boost.org/libs/functional/
http://www.boost.org/libs/bind
If now, what functionality that functional library provides that bind library does not?
The functional library is a better way of using a number of adapters in the current C++ standard library for creating function objects. Bind is much more advanced, and much easier, than using the C++ standard library adapters, and is a much better paradigm for using function objects. The only adapters in the functional library you still might want to use with bind are the Negators, whereas bind very adequately replaces the rest of functional, and its original C++ standard equivalents. Bind also offers more advanced functionality, mostly having to do with argument replacement and manipulation when calling the bound (member) function. You might also want to look at Boost lambda, which is similar to the functionality which bind offers, using a different more in-line syntax, which is not intended to save the function object for later use, when calling a bound (member) function. Boost lambda needs a highly C++ compliant compiler, and a number of older or lesser C++ compliant compilers do not work with Boost lambda. A Boost bind object, which is a C++ function object, can be saved as a Boost function, for use as a callback, or used in Boost signals as a signal handler.

David Greene wrote:
I'm starting to use boost::program_options and am not having much luck:
Some more information: I'm using Boost 1.33.1 with g++ 4.0.2 on x86 Linux. When I switch to g++ 3.3.3 running the test with no options works. Running with --help works. Running with any --debug options causes a segfault. Any ideas on where to start? -Dave

David Greene wrote:
David Greene wrote:
I'm starting to use boost::program_options and am not having much luck:
Some more information:
I'm using Boost 1.33.1 with g++ 4.0.2 on x86 Linux. When I switch to g++ 3.3.3 running the test with no options works. Running with --help works. Running with any --debug options causes a segfault.
After some investigation I discovered that the first "free(): Invalid pointer" message appears during execution cmdline::run. At line 244 of cmdline.cpp, there's a break statement that triggers the destruction of local vector<option> next. Valgrind reports the bad free and I've attached the report below. Hopefully that will be helpful. I'm willing to patch my sources in the short term but I need some help determining the problem. I'm not familiar with the internals of program_options. Thanks. -Dave ----------------- Valgrind report ==31224== Invalid free() / delete / delete[] ==31224== at 0x1B8FF622: operator delete(void*) (vg_replace_malloc.c:246) ==31224== by 0x80509E8: __gnu_cxx::new_allocator<boost::program_options::basic_option<char>
::deallocate(boost::program_options::basic_option<char>*, unsigned) (new_allocator.h:94) ==31224== by 0x8050A12: std::_Vector_base<boost::program_options::basic_option<char>, std::allocator<boost::program_options::basic_option<char> > ::_M_deallocate(boost::program_options::basic_option<char>*, unsigned) (stl_vector.h:123) ==31224== by 0x8050A51: std::_Vector_base<boost::program_options::basic_option<char>, std::allocator<boost::program_options::basic_option<char> > ::~_Vector_base() (stl_vector.h:109) ==31224== by 0x8052D4B: std::vector<boost::program_options::basic_option<char>, std::allocator<boost::program_options::basic_option<char> > >::~vector() (stl_vector.h:273) ==31224== by 0x1B93834A: boost::program_options::detail::cmdline::run() (cmdline.cpp:244) ==31224== by 0x80541C3: boost::program_options::basic_command_line_parser<char>::run() (parsers.hpp:102) ==31224== by 0x80542BE: boost::program_options::basic_parsed_options<char> boost::program_options::parse_command_line<char>(int, char**, boost::program_options::options_description const&, int, boost::function1<std::pair<std::string, std::string>, std::string const&, std::allocator<boost::function_base> >) (parsers.hpp:119) ==31224== by 0x804EEBC: test::process_options(int, char**) (options.cc:69) ==31224== by 0x804F177: main (options.cc:87) ==31224== Address 0x1BCA7200 is 1096 bytes inside a block of size 1152 alloc'd ==31224== at 0x1B8FE899: malloc (vg_replace_malloc.c:149) ==31224== by 0x1BC7F3BD: operator new(unsigned) (new_op.cc:48) ==31224== by 0x1BC6BC10: std::__default_alloc_template<true, 0>::_S_chunk_alloc(unsigned, int&) (stl_alloc.h:109) ==31224== by 0x1BC6BB1C: std::__default_alloc_template<true, 0>::_S_refill(unsigned) (stl_alloc.h:561) ==31224== by 0x1BC6B60B: std::__default_alloc_template<true, 0>::allocate(unsigned) (stl_alloc.h:365) ==31224== by 0x1BC716E7: std::string::_Rep::_S_create(unsigned, std::allocator<char> const&) (stl_alloc.h:685) ==31224== by 0x1BC724F4: char* std::string::_S_construct<char const*>(char const*, char const*, std::allocator<char> const&, std::forward_iterator_tag) (basic_string.tcc:150) ==31224== by 0x1BC6E7B3: std::string::string(char const*, std::allocator<char> const&) (basic_string.h:732) ==31224== by 0x1B942DB5: boost::program_options::option_description::set_name(char const*) (options_description.cpp:115) ==31224== by 0x1B942873: boost::program_options::option_description::option_description(char const*, boost::program_options::value_semantic const*, char const*) (options_description.cpp:49) ==31224== by 0x1B943295: boost::program_options::options_description_easy_init::operator()(char const*, char const*) (options_description.cpp:172) ==31224== by 0x804EBB1: test::process_options(int, char**) (options.cc:46) ==31224==

David Greene wrote:
I'm willing to patch my sources in the short term but I need some help determining the problem. I'm not familiar with the internals of program_options.
This _may_ be due to a standard library mismatch problem. I'm looking at that right now so don't work too hard on this yet. :) -Dave

David Greene wrote:
David Greene wrote:
I'm willing to patch my sources in the short term but I need some help determining the problem. I'm not familiar with the internals of program_options.
This _may_ be due to a standard library mismatch problem. I'm looking at that right now so don't work too hard on this yet. :)
Indeed, this was the problem. Apologies for the noise. -Dave
participants (3)
-
David Greene
-
Edward Diener
-
yinglcs2@yahoo.com