目前我正在使用boost::program_options
解析 BeagleBoard(基于 ARM 的处理器)上的配置文件。我的程序是多线程的并与boost 1.45 multithreaded
库链接。
我的程序在解析配置文件时似乎只是挂起
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;
程序在打印出“添加选项后”之前挂起。如果我通过 gdb 运行程序并停止它并进行回溯,它只会显示它在“永远不会到达这里”评论之前就在线。回溯的顶部只是在
#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
...(如果您想要更多,请告诉我)
有什么想法吗?该程序在 x86 机器上运行良好
编辑:更多信息,这似乎不会在优化关闭时发生(使用 -O2 编译,这将相当一致地发生)。
Edit2:进一步的分析表明,这仍然会在优化关闭时发生,-O0。