in boost 1.46.1 program_options lib is unusable in macports

[christophe.prudhomme@…]

the following simple program using boost.program_options crashes with the boost macports

#include <iostream>

#include <boost/program_options.hpp>
namespace po = boost::program_options;
int main(int ac, char** av)
{
	using namespace std;
//locale::global(locale(""));
// Declare the supported options.
po::options_description desc("Allowed options");
desc.add_options()
    ("help", "produce help message")
    ("compression", po::value<int>(), "set compression level")
;

po::variables_map vm;
po::store(po::parse_command_line(ac, av, desc), vm);
po::notify(vm);

if (vm.count("help")) {
	cout << desc << "\n";
    return 1;
}

if (vm.count("compression")) {
    cout << "Compression level was set to "
 << vm["compression"].as<int>() << ".\n";
} else {
    cout << "Compression level was not set.\n";
}
}

the problem lies in printing the options_description structure

(gdb) r --help
Starting program: /private/tmp/t --help
Allowed options:
t(40384) malloc: *** error for object 0x7fff70a22500: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug

Program received signal SIGABRT, Aborted.
0x00007fff88cab5d6 in __kill ()
(gdb) bt
#0  0x00007fff88cab5d6 in __kill ()
#1  0x00007fff88d4bcd6 in abort ()
#2  0x00007fff88c636b5 in free ()
#3  0x00000001001299d0 in std::basic_stringbuf<char, std::char_traits<char>, std::allocator<char> >::overflow ()
#4  0x000000010012e13c in std::basic_streambuf<char, std::char_traits<char> >::xsputn ()
#5  0x00007fff84fcdae4 in std::__ostream_write<char, std::char_traits<char> > ()
#6  0x00007fff84fcbb98 in std::__ostream_insert<char, std::char_traits<char> > ()
#7  0x0000000100063b3d in boost::program_options::options_description::print ()
#8  0x00000001000640b7 in boost::program_options::operator<< ()
#9  0x00000001000016cf in main ()

[christophe.prudhomme@…]

test program to reproduce the crash

[christophe.prudhomme@…]

Note that the example is taken from the boost.program_options from the tutorial I suspect this has to do with utf-8 encoding and locales.

[adfernandes (Andrew Fernandes)]

Hmm... your test file (and my own program_options programs) works for me. Compiled with

g++ -I /opt/local/include -L /opt/local/lib t.cpp -lboost_program_options -o t

using the default gcc-4.2.1 compiler under 10.6.7.

What compiler and OS are you running?

[christophe.prudhomme@…]

it seems that it is related to the compiler If I force using /usr/bin/g++ then ./t --help is fine If I use /opt/local/bin/g++ (g++-4.5 in fact) then I have the problem mentioned in this bug report If I use g++-mp-4.4 same issue

Unfortunately I have to use g++-4.5 (or g++-4.4) for my own software because g++-4.2 does not support some of the std c++0x features

I am using the latest version of snow leopard

hwprefs os_type

Mac OS X 10.6.7 (10J869)

boost 1.46 is compiled with /usr/bin/g++

[christophe.prudhomme@…]

Could it be that this is an incompatibility between g++-4.2 and g++-4.4 or g++-4.5 ? it seems so

[adfernandes (Andrew Fernandes)]

Just tried it with g++-mp-4.5 and had no problem. Your test-case compiles and runs fine for me. I do not have the MacPorts 4.3 or 4.4 compilers on my system, so cannot test them.

Are you sure you're linking the dylib for boost? I've seen problems like this (mixing gcc versions) when dylibs (or so files on LInux) are not compiled properly. Exception-handling frames and stuff like that in particular gets messed up.

Alternatively, try force-linking the static boost library. Do that as follows:

g++ -I /opt/local/include /opt/local/lib/libboost_program_options.a t.cpp -o t

and do not add any -L or -l options, otherwise the dylib will silently be used! Verify that the static lib is being used by otool -L t and ensure that there are no links to the boost dylib.

(Both static and dynamic linking work for me, with both the system and macports 4.5 compiler.)

You can also try recompiling boost and seeing if the problem goes away. Also... gcc45 was just updated, so maybe re-install it, too... (after a sudo port update, of course!)

Does any of this help?

[christophe.prudhomme@…]

unfortunately no, it does not help :( I still get those crashes unless I use g++-4.2

I suspect a problem with locales and utf8 here is the backtrace of the crash

(gdb) r
Starting program: /private/tmp/t 
Reading symbols for shared libraries +++. done
t(7424) malloc: *** error for object 0x100158ae0: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug

Program received signal SIGABRT, Aborted.
0x00007fff88cab5d6 in __kill ()
(gdb) bt
#0  0x00007fff88cab5d6 in __kill ()
#1  0x00007fff88d4bcd6 in abort ()
#2  0x00007fff88c636b5 in free ()
#3  0x00000001000e9735 in std::string::assign ()
#4  0x000000010001182c in std::string::operator= () at /usr/include/c++/4.2.1/bits/basic_string.h:156
#5  0x000000010001182c in boost::program_options::option_description::set_name (this=0x100300180, _name=<value temporarily unavailable, due to optimizations>) at libs/program_options/src/options_description.cpp:156
#6  0x0000000100011940 in boost::program_options::option_description::option_description (this=0x100300180, name=0x100027bcc "help", s=0x100300170, description=<value temporarily unavailable, due to optimizations>) at libs/program_options/src/options_description.cpp:66
#7  0x0000000100014ed2 in shared_ptr<boost::program_options::option_description> [inlined] () at :67
#8  0x0000000100014ed2 in boost::program_options::options_description_easy_init::operator() (this=0x7fff5fbff9f0, name=0x100027bcc "help", description=0x100027bb7 "produce help message") at libs/program_options/src/options_description.cpp:206
#9  0x0000000100001021 in main () at utf8_codecvt_facet.hpp:111

what do you think ?

[christophe.prudhomme@…]

Interestingly here is something else:

• with static lib

it crashes whatever I do ( no arguments, --help, --compression=1...) the backtrace is the one in the previous message

• with dylib

it crashes only when I pass --help

In the last case The problem is when the options_description data structure is getting passed std::cout here is the backtrace in that case

(gdb) bt
#0  0x00007fff88cab5d6 in __kill ()
#1  0x00007fff88d4bcd6 in abort ()
#2  0x00007fff88c636b5 in free ()
#3  0x0000000100114a83 in std::basic_stringbuf<char, std::char_traits<char>, std::allocator<char> >::overflow ()
#4  0x00000001001191fc in std::basic_streambuf<char, std::char_traits<char> >::xsputn ()
#5  0x00007fff84fcdae4 in std::__ostream_write<char, std::char_traits<char> > ()
#6  0x00007fff84fcbb98 in std::__ostream_insert<char, std::char_traits<char> > ()
#7  0x000000010004eb3d in boost::program_options::options_description::print ()
#8  0x000000010004f0b7 in boost::program_options::operator<< ()
#9  0x0000000100001680 in main ()

[ghost@…]

In general, such makes-no-sense crashes occur when you mix up different versions of libraries, etc. I'd recommend making static linking case work, first.

For starters, what is up with this line in backtrace:

#9 0x0000000100001021 in main () at utf8_codecvt_facet.hpp:111

This makes no sense whatsoever. May I recommend that when compiling, run gcc with the -save-temps option. Examine the <input-file-name>.ii file and note where program_options includes are found. Then, make sure that the created binary is static, and does not use any shared libraries at all. I think you need to pass -static to gcc for that to be the case. I suppose that checking that binary is static can be done with 'otool' with some appropriate switches.

[christophe.prudhomme@…]

Vladimir

thanks for taking a look at this

boost 1.46.1 is compiled with g++-4.2 installed on MacOsX while I compiled my codes with g++-4.5 (or 4.4) could it be some kind of incompatibility between 4.2 (boost program_options lib is compiled with that) and 4.5 (the executable is compiled with that) ?

know also that if the code is compiled with gcc 4.2 then there is no crash at all.

I tried what you suggest, -static didn't work though as crt0.o is missing. The .ii file is all right

[christophe.prudhomme@…]

I have recompiled the boost library with the variant +debug If I use the static -d version of the po lib then no crash with g++45, g++44 and g++4.2 If I use the dylib -d version of the po lib then crash with 45 and 44 If I use the non -d version then crash for 45 and 44

I checked with --save-temps and otool that the right headers and dylibs were used.

[adfernandes (Andrew Fernandes)]

Given your description, I'd say that there is a compiler incompatibility somewhere, most likely due to optimization. Could be a bug - maybe or maybe not.

I have hit hard-to-diagnose problems like this when mixing gcc versions before. That was my primary argument for making different compiler variants of the pymol port.

If you absolutely need gcc-4.5, I would recommend that you try to install and build a local copy of boost using the gcc-4.5 compiler. If you follow the boost website directions it shouldn't be too difficult to specify a custom compiler in the jamfile... but beyond that, I think that this bug is out of scope, especially since I cannot reproduce it.