Re: [Boost-users] [boost::program_options] bad_function_call and -g

From: Vladimir Prus (ghost_at_[hidden])
Date: 2005-08-16 05:13:56

alexandre.ignjatovic_at_[hidden] wrote:

> Does anyone know why i get a bad_function_call at the execution of this
> code (compiled without the '-g' option):
> 
>     namespace bpo = boost::program_options;
>     _optDesc.add_options()
>         ("version,v", "print version")
>         ("help,h", "print this help message")
>         ("config-file,f",
>          bpo::value<std::string>(&_cfg)->default_value(_cfg),
>          "specify configuration file")
>         ("id,i",
>          bpo::value<std::string>(&_id)->default_value(a_id),
>          "specify server identifier");
>     bpo::variables_map vm;
>     bpo::store(bpo::parse_command_line(argc, argv, _optDesc), vm);
>     bpo::notify(vm);
> 
> while it runs correctly with "-g" ?

Sound like compiler bug.

> 
> Compiler : gcc 343 (linux) or cc 57 (solaris)
> Boost version: 1.32.0

So, the problem is present on two compilers? Then it's not likely be to a
compiler bug. Are you sure that "-g" is the only difference in command
lines? Are there any extra defines or something?

Does it crash if you compile with "-g" and then run "strip" on the binary?

> The exception seems to be trown by the notify function. By the way, it is
> quit hard to trace undebuggable compiled code (no -g, no way :))

It's possible to try this:
1. Build application with -g (say, creating file hello)
2. Copy application to hello_stripped
3. Run "strip hello_stripped"
4. In one terminal, run "gdbserver localhost:1777 hello_stripped"
5. In another terminal, run "gdb hello"
6. At gdb command prompt, type "target remote localhost:1777"

After that, you'll be running non-debug version of binary, but gdb will be
using symbols from the debug binary.

Or, you can do the same without "strip" -- just create two versions -- with
-g and without -g and use the same trick with "gdbserver" and "target
remote".

HTH,
Volodya