program_options and lib64

Hello, I am using linux gcc 4.01, boost-1.33 on an amd 64 machine. I use program_options to retrieve a string from a config file but get a crash like this when I notify(): Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 46912541228512 (LWP 12633)] 0x00002aaaab14d2eb in std::string::assign () from /usr/lib64/libstdc++.so.6 (gdb) bt #0 0x00002aaaab14d2eb in std::string::assign () from /usr/lib64/libstdc++.so.6 #1 0x0000000000427689 in boost::program_options::typed_value<std::string, char>::notify (this=0x5de300, value_store=@0x5e1a48) at value_semantic.hpp:32 #2 0x00002aaaaafa50c9 in boost::program_options::notify () from /usr/local/lib/libboost_program_options-gcc-1_33.so.1.33.0 Is there known uncompatibilities between boost/gcc4/lib64 ?? Thank you, -- Philippe Després Associate Specialist UCSF Physics Research Lab 185 Berry Street suite 350 San Francisco CA 94107 (415) 353-4501 PGP PUBLIC KEY http://itsa.ucsf.edu/~despres/publickey.txt

Philippe Despr?s wrote:
There were recent thread on this list with title "[program options] seg fault on ppc64 / linux / gcc 3.4.4", which ended with detecting a problem in shared_ptr, and a proposed patch that fixes the problem. I'm not sure this is the problem that affects you, but first of all I'd try to apply that patch. Another kind of problem was using 'unsigned' instead of string::size_type, which are different types on 64 bit boxes. However, looking at config file code, I don't see any remaining usages of 'unsigned'. I'm afraid I'd need more information to understand the problem. For example, if you position debugger at frame #1 above (in typed_value::notify), what are the values of 'm_store_to' and 'value'. What are the values of '*value' and '*m_store_to'. Do they look sane? What is the minimal example that reproduces the problem? - Volodya

Philippe Després wrote:
<snip> To facilitate hunting this down, I would recommend you get yourself a copy of the latest valgrind, which finally supports amd64 and let your program run under the control of valgrind. I'm pretty sure it will point right at the cause of the error. Markus
participants (3)
-
Markus Schöpflin
-
Philippe Després
-
Vladimir Prus