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

From: alexandre.ignjatovic_at_[hidden]
Date: 2005-08-16 08:21:18

> 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

Correction: i was wrong, there isn't any problem with gcc (Teamwork and
communication...). Like you said, this seems to be a compiler bug.

> 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?

Only few differences between compilation options:
Debug   : -g
Release : +w -x03

The other options are similar in both mode.

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

Well, yes, it crashes too.

>> 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".

Wow, i didn't know that was possible, thanks for the info. I'm gonna bribe
the sysadmin for him to install gdbserver.

Thanks a lot.

-- 
Alexandre Ignjatovic