[program_options] add_options method hangs on Linux
Hi, I have a piece of code that runs both on Windows and Linux. I am using program_options library to read a settings file. This seems to work fine on windows, but on Linux the same code hangs when I call add_options method. I am using Boost 1.34 on both machines. Any suggestions on what may be causing this problem are greatly appreciated. Inga
Farberov, Inga wrote:
Hi,
I have a piece of code that runs both on Windows and Linux. I am using program_options library to read a settings file.
This seems to work fine on windows, but on Linux the same code hangs when I call add_options method.
I am using Boost 1.34 on both machines.
Any suggestions on what may be causing this problem are greatly appreciated.
Please provide a complete and minimal example that reproduces the problem. - Volodya
For some reason I am unable to reproduce this problem in a small program, but when try to suspend a hanging thread in debugger, I get following stack trace: 18 _dl_sysinfo_int80() 0x003317a2 17 __lll_mutex_lock_wait() 0x0062e30e 16 _L_mutex_lock_35() 0x0062af3b 15 <symbol is not available> 0x080c80e8 14 <symbol is not available> 0x00472ff4 13 <symbol is not available> 0x080c80e8 12 <symbol is not available> 0xbffff6b0 11 <symbol is not available> 0xbffff208 10 pthread_mutex_lock() 0x0042097e 9 pthread_mutex_lock() 0x0042097e 8 scoped_lock() /usr/include/boost/detail/lwm_pthreads.hpp:72 0x080598eb 7 boost::detail::sp_counted_base::add_ref_copy() /usr/include/boost/detail/shared_count.hpp:122 0x0805b679 6 shared_count() /usr/lib/boost/include/boost-1_34/boost/detail/shared_count.hpp:216 0x0805b65b 5 shared_ptr() /usr/include/c++/3.4.6/bits/stl_construct.h:81 0x0807a7c8 4 boost::program_options::options_description_easy_init::operator() libs/program_options/src/options_description.cpp:178 0xb7fd7189 3 Settings() ../Settings.cpp:9 0x08081808
Hi,
I have a piece of code that runs both on Windows and Linux. I am using program_options library to read a settings file.
This seems to work fine on windows, but on Linux the same code hangs when I call add_options method.
I am using Boost 1.34 on both machines.
Any suggestions on what may be causing this problem are greatly appreciated.
Please provide a complete and minimal example that reproduces the problem. - Volodya _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Farberov, Inga wrote:
For some reason I am unable to reproduce this problem in a small program, but when try to suspend a hanging thread in debugger, I get following stack trace: 18 _dl_sysinfo_int80() 0x003317a2 17 __lll_mutex_lock_wait() 0x0062e30e 16 _L_mutex_lock_35() 0x0062af3b 15 <symbol is not available> 0x080c80e8 14 <symbol is not available> 0x00472ff4 13 <symbol is not available> 0x080c80e8 12 <symbol is not available> 0xbffff6b0 11 <symbol is not available> 0xbffff208 10 pthread_mutex_lock() 0x0042097e 9 pthread_mutex_lock() 0x0042097e 8 scoped_lock() /usr/include/boost/detail/lwm_pthreads.hpp:72 0x080598eb 7 boost::detail::sp_counted_base::add_ref_copy() /usr/include/boost/detail/shared_count.hpp:122 0x0805b679 6 shared_count() /usr/lib/boost/include/boost-1_34/boost/detail/shared_count.hpp:216 0x0805b65b 5 shared_ptr() /usr/include/c++/3.4.6/bits/stl_construct.h:81 0x0807a7c8 4 boost::program_options::options_description_easy_init::operator()
This stacktrace suggest that you've built your application with single-threading, and linked it to multi-threaded build of program_options, or vice versa. I don't think I can suggest more without the real code and specific information how you build it. - Volodya
For some reason I am unable to reproduce this problem in a small program, but when try to suspend a hanging thread in debugger, I get following stack trace: 18 _dl_sysinfo_int80() 0x003317a2 17 __lll_mutex_lock_wait() 0x0062e30e 16 _L_mutex_lock_35() 0x0062af3b 15 <symbol is not available> 0x080c80e8 14 <symbol is not available> 0x00472ff4 13 <symbol is not available> 0x080c80e8 12 <symbol is not available> 0xbffff6b0 11 <symbol is not available> 0xbffff208 10 pthread_mutex_lock() 0x0042097e 9 pthread_mutex_lock() 0x0042097e 8 scoped_lock() /usr/include/boost/detail/lwm_pthreads.hpp:72 0x080598eb 7 boost::detail::sp_counted_base::add_ref_copy() /usr/include/boost/detail/shared_count.hpp:122 0x0805b679 6 shared_count() /usr/lib/boost/include/boost-1_34/boost/detail/shared_count.hpp:216 0x0805b65b 5 shared_ptr() /usr/include/c++/3.4.6/bits/stl_construct.h:81 0x0807a7c8 4 boost::program_options::options_description_easy_init::operator()
This stacktrace suggest that you've built your application with single-threading, and linked it to multi-threaded build of program_options, or vice versa. I don't think I can suggest more without the real code and specific information how you build it. - Volodya My code is broken down into 2 projects - one compiles into a static library and the other into an executable that is referring to the static library. I am using several boost libraries - multithreaded versions. When I compile and link I use -pthread compiler flag. By the way, I did an experiment where I commented out everything in my main method and only left a call to the trouble-maker class. Everything works fine then. In the same file I also have a helper function that uses shared_ptr library. When I uncomment that function, but don't envoke it, I still get the same problem. Is there anything else I should be doing to get this to work correctly? Inga
Farberov, Inga wrote:
For some reason I am unable to reproduce this problem in a small program, but when try to suspend a hanging thread in debugger, I get following stack trace: 18 _dl_sysinfo_int80() 0x003317a2 17 __lll_mutex_lock_wait() 0x0062e30e 16 _L_mutex_lock_35() 0x0062af3b 15 <symbol is not available> 0x080c80e8 14 <symbol is not available> 0x00472ff4 13 <symbol is not available> 0x080c80e8 12 <symbol is not available> 0xbffff6b0 11 <symbol is not available> 0xbffff208 10 pthread_mutex_lock() 0x0042097e 9 pthread_mutex_lock() 0x0042097e 8 scoped_lock() /usr/include/boost/detail/lwm_pthreads.hpp:72 0x080598eb 7 boost::detail::sp_counted_base::add_ref_copy() /usr/include/boost/detail/shared_count.hpp:122 0x0805b679 6 shared_count() /usr/lib/boost/include/boost-1_34/boost/detail/shared_count.hpp:216 0x0805b65b 5 shared_ptr() /usr/include/c++/3.4.6/bits/stl_construct.h:81 0x0807a7c8 4 boost::program_options::options_description_easy_init::operator()
This stacktrace suggest that you've built your application with single-threading, and linked it to multi-threaded build of program_options, or vice versa.
My code is broken down into 2 projects - one compiles into a static library and the other into an executable that is referring to the static library. I am using several boost libraries - multithreaded versions. When I compile and link I use -pthread compiler flag.
I still believe you've missed -pthread somewhere, or linking to non-mt version of program_option (or some other library).
By the way, I did an experiment where I commented out everything in my main method and only left a call to the trouble-maker class. Everything works fine then.
Lacking code, I have no idea what's "main method", what's "trouble-maker class", how one can call a class, and what conclusions can be made here.
In the same file I also have a helper function that uses shared_ptr library. When I uncomment that function, but don't envoke it, I still get the same problem.
Again, this suggests that different parts of your program have different opinions about layout of shared_ptr. Likely, because ST/MT mismatch.
Is there anything else I should be doing to get this to work correctly?
As I've said earlier, unless you provide completely reproducible test case, I cannot suggest anything more (and I doubt anybody else will). - Volodya
Inga
participants (1)
-
Farberov, Inga -
Vladimir Prus