2012-08-14 12 views
8

Obecnie używam boost::program_options do parsowania pliku konfiguracyjnego na BeagleBoard (procesor oparty na ARM). Mój program jest wielowątkowy i połączony z bibliotekami boost 1.45 multithreaded.boost :: Program_options wisi na ramieniu "czasami"

Mój program po prostu wydaje się zawiesić podczas parsowania pliku konfiguracyjnego chociaż

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; 

Program wiesza przed wydrukowaniem out „Po dodaniu opcji”. Jeśli uruchomię program za pomocą gdb, zatrzymam go i wykonam powrót do tyłu, po prostu pokazuje, że był na linii przed komentarzem "Nigdy tu nie ma". Wierzchołek backtrace po prostu musi go w

#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 

... (daj mi znać, jeśli chcesz więcej)

jakieś przemyślenia? Ten program działa poprawnie na maszynie x86

Edycja: Dalsze informacje, nie wydaje się, aby to miało miejsce przy wyłączonych optymalizacjach (skompilowanych z opcją -O2, która będzie dość konsekwentnie występować).

Edycja2: Dalsza analiza wykaże, że nadal zdarza się to przy wyłączonych optymalizacjach, -O0.

+0

Czy możesz pokazać, co śledzenie drukuje po # 2? –

+0

dlaczego ma spację w nazwie opcji? –

+0

Sprawdź, który wątek trzyma blokadę i zobacz, co aktualnie robi ten wątek. Możliwe, że nadpisałeś swój zamek śmieciami i/lub używasz niezainicjowanej struktury zamka. – PlasmaHH

Odpowiedz

1

Może to być problem związany z budowaniem wzmocnienia i aplikacją. Implementacje blokady mutex są różne, jeśli kompilujesz dla kciuka i bez kciuka. Upewnij się, że kompilujesz zarówno aplikację, jak i bibliotekę boost z tymi samymi ustawieniami kciuka.

Oto przykład user-config.jam używam skompilować 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 
; 

Zauważ, że w tym przykładzie, nie skompilować z kciukiem włączone.

+0

Okazało się, że tak. Co za podstępny, przebiegły problem do zdiagnozowania. Dzięki –

Powiązane problemy