[program_options] Issues with boost::program_options freezing
Hello, Our application is using boost::program_options to parse commandline arguments. We have found that when we perform our own builds of boost from source code, program_options freezes the application hard at variable points in the code (a step through in GDB confirms this). However, when we use pre-built binaries of the program_options library for any of our target OSes (Debian stable, Centos 4, Fedora 4) the application runs properly. We are also using the boost::thread library. Are there thread safety or interaction issues between thread and program_options that I am not aware of? We are using 1.32 due a change in the behavior of program_options in 1.33. This script shows how we are building boost. # run configure cd libs/config || fail-configure chmod +x configure || fail "error: could not change permissions on ${PACKAGE} configure script" ./configure || fail-configure cp user.hpp ../../boost/config/ cd ../.. # build and install libraries BOOST_LIBS="date_time filesystem program_options regex thread" for LIB in ${BOOST_LIBS}; do echo "Building library ${LIB}..." bjam -sTOOLS=gcc -sBUILD="release threading=multi" --with-${LIB} \ --layout="system" stage 2>&1 || \ fail "error: could not build boost library ${LIB}" bjam -sTOOLS=gcc -sBUILD="release threading=multi" --with-${LIB} --layout="system" \ --prefix=`pwd`/../../${INSTALL_DIR} install 2>&1 || \ fail "error: could not install boost library ${LIB}" done Thanks in advance. -- Zach
Zachary Mark <zmark <at> cleversafe.com> writes:
Hello,
Our application is using boost::program_options to parse commandline arguments. We have found that when we perform our own builds of boost from source code, program_options freezes the application hard at variable points in the code (a step through in GDB confirms this). However, when we use pre-built binaries of the program_options library for any of our target OSes (Debian stable, Centos 4, Fedora 4) the application runs properly.
We are also using the boost::thread library. Are there thread safety or interaction issues between thread and program_options that I am not aware of? We are using 1.32 due a change in the behavior of program_options in 1.33. This script shows how we are building boost.
You did not indicate where the library hangs (i.e. did not provide a complete backtrace). If it's in some threading-related function, it means that you're using wrong version of the library. If you application is multi-threaded, you must link to MT build of program_options. One important aspect of this is that MT mode changes layout of shared_ptr, which is used in program_options public interface, so mismatch in MT mode between the library and the program causes sure problems.
# run configure
cd libs/config || fail-configure chmod +x configure || fail "error: could not change permissions on ${PACKAGE} configure script" ./configure || fail-configure cp user.hpp ../../boost/config/
cd ../..
# build and install libraries
BOOST_LIBS="date_time filesystem program_options regex thread"
for LIB in ${BOOST_LIBS}; do echo "Building library ${LIB}..." bjam -sTOOLS=gcc -sBUILD="release threading=multi" --with-${LIB} \ --layout="system" stage 2>&1 || \ fail "error: could not build boost library ${LIB}" bjam -sTOOLS=gcc -sBUILD="release threading=multi" --with-${LIB} --layout="system" \ --prefix=`pwd`/../../${INSTALL_DIR} install 2>&1 || \ fail "error: could not install boost library ${LIB}" done
Thanks in advance.
Well, this looks reasonable. Do you build your own application in such a way that Boost things its multi-threaded? - Volodya
Vladimir Prus wrote:
Zachary Mark <zmark <at> cleversafe.com> writes:
Hello,
Our application is using boost::program_options to parse commandline arguments. We have found that when we perform our own builds of boost from source code, program_options freezes the application hard at variable points in the code (a step through in GDB confirms this). However, when we use pre-built binaries of the program_options library for any of our target OSes (Debian stable, Centos 4, Fedora 4) the application runs properly.
We are also using the boost::thread library. Are there thread safety or interaction issues between thread and program_options that I am not aware of? We are using 1.32 due a change in the behavior of program_options in 1.33. This script shows how we are building boost.
You did not indicate where the library hangs (i.e. did not provide a complete backtrace). If it's in some threading-related function, it means that you're using wrong version of the library. If you application is multi-threaded, you must link to MT build of program_options. One important aspect of this is that MT mode changes layout of shared_ptr, which is used in program_options public interface, so mismatch in MT mode between the library and the program causes sure problems.
After some testing, I've determined that it is definitely a library mismatch (this is what I expected it to be, actually). A straight up bjam build without the build script and then manually copying the appropriate library works fine. Using the script-produced library produces the hang (I did a stack trace and it looks like it is getting hung up on a thread wait). I'm not sure what the issue could be with the build script but it's no longer in Boost-land in terms of what is causing the hang. Thanks for the assistance. -- Zach
participants (3)
-
Vladimir Prus -
Zachary Mark