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

From: Vladimir Prus (ghost_at_[hidden])
Date: 2005-08-17 00:46:21

alexandre.ignjatovic_at_[hidden] wrote:

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

Are you building both program_options and your program with the same flags? 
I don't know what's -x03 is but it might be possible that it changes some
data layout somewhere.

If the options are the same both for program_options and your program, then
it really looks like compiler bug. We probably can try to workaround it
somehow, but we need to know the exact place where it happens.

>> Does it crash if you compile with "-g" and then run "strip" on the
>> binary?
> 
> Well, yes, it crashes too.

Ahm... then again it does not look like a compiler bug. "Strip" simply
removes debug info sections. 

It possible that there's some unintilized variable, or something. Maybe you
can try getting the valgrind tool (http://valgrind.org) and running your
program with:

   valgrind your_program

this will report any uses of uninitialized data. OTOH, valgrind only works
for Linux/x86 where your program does not crash. But maybe that will help.

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

I always thought gdbserver is in the same package that gdb, for all possible
systems, but anyway, good luck with the sysadmin.

You might also try the 1.33 version of Boost.

- Volodya