boost::program_options hangs on the arm "sometimes"

Question

Currently I am using boost::program_options to parse a configuration file on the BeagleBoard (ARM-based processor). My program is multi-threaded and linked against the boost 1.45 multithreaded libraries.

My program just seems to hang when parsing the configuration file though

namespace po = boost::program_options;
po::options_description desc("Options");
uint32_t option1=0;
std::vector<std::string> optionsString;
std::cout<<"Before adding options"<<std::endl;
desc.add_options()
    ("option1",
     po::value<uint32_t>(&option1), "...")
    ("finaloption",
     po::value<std::vector<std::string> >(&optionsString)->multitoken(), "string of options");
//Never gets here
std::cout<<"After adding options"<<std::endl; 
po::variables_map vm;
std::cout<<"Starting program"<<std::endl;

The program hangs before printing out "After adding options". If I run the program through gdb stop it and do a back trace it just shows that it was on the line before the "Never gets here" comment. The top of the backtrace just has it at

#0 ??
#1 __lll_lock_wait lowlevellock.c:47
#2 __pthread_mutex_lock pthread_mutex_lock.c:61
#3 in boost::shared_ptr<boost::program_options::option_description>* std::__uninitialized_move_a<boost::shared_ptr<boost::program_options::option_description>*, boost::shared_ptr<boost::program_options::option_description>*, std::allocator<boost::shared_ptr<boost::program_option::option_description> > >(boost::shared_ptr<boost::program_optionns::option_description>*, boost::shared_ptr<boost::program_options::option_description>*, std::allocator<boost::shared_ptr<boost::program_options::option_description> >&) () from /usr/local/lib/libboost_program_options-mt.so.1.45.0
#4 in std::vector<boost::shared_ptr<boost::program_options::option_description>, std::allocator<boost::shared_ptr<boost::program_options::option_description> > >::_M_insert_aux(__gnu_cxx::__normal_iterator<boost::shared_ptr<boost::program_options::option_description>, std::vector<boost::shared_ptr<boost::program_options::option_description>, std::allocator<boost::shared_ptr<boost::program_options::option_description> const&)() from /usr/local/lib/libboost_program_options-mt.so.1.45.0
#5 in boost::program_options::options_description::add(boost::shared_ptr<boost::program_options::option_description>) () from /usr/local/lib/libboost_program_options-mt.so.1.45.0

...(let me know if you want more)

Any thoughts? This program works fine on an x86 machine

Edit: Further information, this does not seem to happen with optimizations off (compiled with -O2 this will fairly consistently occur).

Edit2: Further analysis reveals that this still happens with optimizations off, -O0.

Look which thread is holding the lock, and look what that thread is currently doing. You might also have overwritten your lock with garbage and/or are using uninitialized lock structure. — PlasmaHH, Aug 14 '12 at 14:20
How do I go about doing that in GDB? Also, I only create and start the threads after this in the program... — Adam A., Aug 14 '12 at 14:29
Would [this](https://lkml.org/lkml/2011/9/28/534) explain it? — Adam A., Aug 14 '12 at 15:12
This might not have much to do with Boost.ProgramOptions, but your libc. What libc and version are you using? — Daniel Trebbien, Aug 26 '12 at 22:33
This could be a problem related to how you build boost and your application. The mutex lock implementations are different if you compile for thumb and without thumb. Make sure you compile both the application and the boost library with the same thumb settings. — user1095108, Aug 27 '12 at 08:16

score 2 · Accepted Answer · answered Jan 20 '13 at 16:24

This could be a problem related to how you build boost and your application. The mutex lock implementations are different if you compile for thumb and without thumb. Make sure you compile both the application and the boost library with the same thumb settings.

Here's an example user-config.jam I use to compile boost:

if [ os.name ] = CYGWIN || [ os.name ] = NT
{
    HOST_TAG = windows ;
}
else if [ os.name ] = LINUX
{
    HOST_TAG = linux-x86 ;
}
else if [ os.name ] = MACOSX
{
    HOST_TAG = darwin-x86 ;
}

modules.poke : NO_BZIP2 : 1 ;
modules.poke : NO_GZIP : 1 ;

LIB_ROOT = /home/user/lib ;

NDK_ROOT = $(LIB_ROOT)/android-ndk-r8c ;

LLVM_VERSION = 3.1 ;
LLVM_NAME = llvm-$(LLVM_VERSION) ;
LLVM_TOOLCHAIN_ROOT = $(NDK_ROOT)/toolchains/$(LLVM_NAME) ;
LLVM_TOOLCHAIN_PREBUILT_ROOT = $(LLVM_TOOLCHAIN_ROOT)/prebuilt/$(HOST_TAG) ;
LLVM_TOOLCHAIN_PREFIX = $(LLVM_TOOLCHAIN_PREBUILT_ROOT)/bin/ ;

TOOLCHAIN_VERSION = 4.6 ;
TOOLCHAIN_NAME = arm-linux-androideabi-$(TOOLCHAIN_VERSION) ;
TOOLCHAIN_ROOT = $(NDK_ROOT)/toolchains/$(TOOLCHAIN_NAME) ;
TOOLCHAIN_PREBUILT_ROOT = $(TOOLCHAIN_ROOT)/prebuilt/$(HOST_TAG) ;
TOOLCHAIN_PREFIX = $(TOOLCHAIN_PREBUILT_ROOT)/bin/arm-linux-androideabi- ;

using clang : $(TOOLCHAIN_VERSION) :
$(LLVM_TOOLCHAIN_PREFIX)clang :
<compileflags>"-gcc-toolchain $(TOOLCHAIN_PREBUILT_ROOT)"
<compileflags>"-isystem $(LLVM_TOOLCHAIN_PREBUILT_ROOT)/lib/clang/$(LLVM_VERSION)/include"
<compileflags>"-isysroot $(NDK_ROOT)/platforms/android-9/arch-arm/usr/include"
<compileflags>-std=gnu++11
<compileflags>-stdlib=libc++
<compileflags>-fomit-frame-pointer
<compileflags>-ffast-math
<compileflags>"-target armv7-none-linux-androideabi"
<compileflags>-march=armv7-a
<compileflags>-mfloat-abi=softfp
<compileflags>-mfpu=neon
<compileflags>-DPAGE_SIZE=sysconf\\(_SC_PAGESIZE\\)
<compileflags>-I$(NDK_ROOT)/boost/include
<compileflags>-I$(NDK_ROOT)/sources/cxx-stl/gnu-libstdc++/$(TOOLCHAIN_VERSION)/include
<compileflags>-I$(NDK_ROOT)/sources/cxx-stl/gnu-libstdc++/$(TOOLCHAIN_VERSION)/libs//armeabi-v7a/include
<compileflags>-I$(NDK_ROOT)/platforms/android-9/arch-arm/usr/include
<linkflags>-s
<archiver>$(TOOLCHAIN_PREFIX)ar
<ranlib>$(TOOLCHAIN_PREFIX)ranlib
;

Note, that in this example, I did not compile with thumb enabled.

It turned out to be this. What a sneaky devious problem to diagnose. Thanks — Adam A., Jul 24 '16 at 16:03

boost::program_options hangs on the arm "sometimes"

1 Answers1