[boost::program_options] bad_function_call and -g
Hi, 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::valuestd::string(&_cfg)->default_value(_cfg), "specify configuration file") ("id,i", bpo::valuestd::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" ? Compiler : gcc 343 (linux) or cc 57 (solaris) Boost version: 1.32.0 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 :)) Thanks in advance. -- Alexandre Ignjatovic
alexandre.ignjatovic@insia.org 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::valuestd::string(&_cfg)->default_value(_cfg), "specify configuration file") ("id,i", bpo::valuestd::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
alexandre.ignjatovic@insia.org 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::valuestd::string(&_cfg)->default_value(_cfg), "specify configuration file") ("id,i", bpo::valuestd::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
alexandre.ignjatovic@insia.org 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
alexandre.ignjatovic@insia.org 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
participants (2)
-
alexandre.ignjatovic＠insia.org -
Vladimir Prus