Boost logo

Boost :

From: Oliver Kullmann (O.Kullmann_at_[hidden])
Date: 2004-12-04 11:59:15


Hello,

I would like to report 3 issues with the
program_options library, 2 of which seem
critical to me:

1) The class boost::program_options::value_semantic
is a polymorphic class (has virtual functions), but
has a non-virtual destructor. Thus, according to the
Standard, Section 5.3.5, Clause 3, calling delete
for a pointer to an object of static type value_semantic,
where the dynamic type is a derived class, results in
undefined behaviour.

Not only is value_semantic meant to be used in a standard
object-oriented way, but also the program_options library
itself uses it in this way, and thus it seems to me, that
it is basically impossible to use this library without running
into undefined behaviour (which must definitely be avoided).

Perhaps the following crash, when using program_options in a trivial
way, is already caused by this error.

2) Consider the following program "Error_program_options"

#include <boost/program_options.hpp>
int main() {
    boost::program_options::options_description d("Options");
}

I compiled it (using g++, version 3.4.3) via

> g++ -g Error_program_options.cpp -lboost_program_options-gcc

I got the warning

/usr/bin/ld: warning: libstdc++.so.5, needed by /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.3/../../../libboost_program_options-gcc.so, may conflict with libstdc++.so.6

(see point 3), but this doesn't seem to be of importance here. Running this program causes a segmentation fault:

> ./a.out
Segmentation fault (core dumped)

Examining the core dump shows, that the program crashed inside a member function for a safe-pointer helper class:

> gdb a.out core
GNU gdb 5.3.92
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i586-suse-linux"...
Core was generated by `./a.out'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/local/lib/libboost_program_options-gcc-1_32.so.1.32.0...done.
Loaded symbols for /usr/local/lib/libboost_program_options-gcc-1_32.so.1.32.0
Reading symbols from /usr/local/lib/libstdc++.so.6...done.
Loaded symbols for /usr/local/lib/libstdc++.so.6
Reading symbols from /lib/i686/libm.so.6...done.
Loaded symbols for /lib/i686/libm.so.6
Reading symbols from /usr/local/lib/libgcc_s.so.1...done.
Loaded symbols for /usr/local/lib/libgcc_s.so.1
Reading symbols from /lib/i686/libc.so.6...done.
Loaded symbols for /lib/i686/libc.so.6
Reading symbols from /usr/lib/libstdc++.so.5...done.
Loaded symbols for /usr/lib/libstdc++.so.5
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
#0 0x0804923a in boost::detail::sp_counted_base::release() (this=0x838dffff)
    at shared_count.hpp:142
142 long new_use_count = --use_count_;

Thus it could be, that the problem reported unter 1) causes the crash here (on the other hand, actually for the
above trivial program no object of type value_semantic seems to be created, but unfortunately I don't
have the time to investigate this further).

3) I'm using g++ version 3.4.3, and I compiled Boost with this compiler, but to whatever library from
Boost I link, I get warning messages like the above; another example

> g++ calender.o -lboost_date_time-gcc
/usr/bin/ld: warning: libstdc++.so.5, needed by /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.3/../../../libboost_date_time-gcc.so, may conflict with libstdc++.so.6

What's the problem here?! (Linking in general seems in Boost not so easy, and thus it would be good to have
a bit more documentation on this. For example in program_options I couldn't find any hint how to compile it.)

Hope someone can shed light on these issues (as I said, for all what I can see, there seems to be a serious
problem with program_options).

Oliver


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk