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

From: alexandre.ignjatovic_at_[hidden]
Date: 2005-08-17 02:44:54

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

Well, i don't know, i'll check it out.

> I don't know what's -x03 is but it might be possible that it changes some
> data layout somewhere.

That's the optimization level 3. No doubt it changes some stuff, but i
already tried without it, and it still crashes.

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

All i can say for the moment is the bad_function_call is thrown from the
"notify" function. More news later.

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

Oops, correction: it still don't crash. (tiredness...)

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

Well, there is a gdb, a gdbtui ("tui"... what's that ?), and that's all.

>
> You might also try the 1.33 version of Boost.

I'll check it out.

Thanks a lot for your help.

-- 
Alexandre Ignjatovic