Boost Users :
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
>>> 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
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,
> 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
>> 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
> 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
>>>> 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 --
>>> -g and without -g and use the same trick with "gdbserver" and "target
>> Wow, i didn't know that was possible, thanks for the info. I'm gonna
>> the sysadmin for him to install gdbserver.
> I always thought gdbserver is in the same package that gdb, for all
> 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
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net