2

I am using scientific linux. I am trying to compile a project that uses a bunch of cpp files. Right now, it compiles successfully, but the values/data I'm getting are definitely wrong.

In the directory user/project/Build, I enter make to compile and link all the cpp files. I then have to go to user/run/ and then type ./run.sh values.txt

When I go to directory /user/project/Build/bin and then type gdb project and then set breakpoints, there are no problems. But when I hit run, I always see Program exited with code 01. It doesn't matter if I set breakpoints in main.cpp or another source file. Isn't gdb supposed to stop at the breakpoint?

  • "Exited with code N" just refers to the value returned from main(). Does it show the correct path in Starting program: after you run? Using gdb ./project (an absolute path) is less error prone. Beyond that, this seems kind of impossible to solve unless you provide at least an SSCCE. Are you saying gdb does this with, e.g. hello world? I bet it doesn't. You have to narrow down the difference. – goldilocks Feb 26 '15 at 22:11
  • yes, it shows the correct path. I also get the same result if I try gdb ./project. Not sure how I can provide an SSCCE. I have main.cpp and a bunch of other cpp files, and each of them have 1000s of lines of code. The program usually runs if I go to user/run and then type ./run.sh values.txt – user4352158 Feb 26 '15 at 22:20
  • If it matters, the entire output before program exited with code 01 is [Thread debugging using libthread_db enabled] warning: File "/opt/apps/ossw/applications/gcc/gcc-4.6/sl6/lib64/libstdc++.so.6.0.16-gdb.py" auto-loading has been declined by your 'auto-load safe-path' set to "/usr/share/gdb/auto-load:/usr/lib/debug:/usr/bin/mono-gdb.py". ProjectName -[function option] <parameter file> – user4352158 Feb 26 '15 at 22:58
  • That's about some autoload file; e.g. a common python one (.py) used with C++ is for prettified dumps of standard container structures. Not loading it probably isn't the cause of your grief. Gilles' answer makes an excellent point, but if that doesn't solve things, you need to start with a breakpoint on the first line of code in main(). If things are still confused...you are perhaps in over your head. Debugging can break hearts, that is the nature of the beast. :( – goldilocks Feb 27 '15 at 1:15
  • ...If you can find someone responsible for this code, they might be able and willing to point you in the right direction. – goldilocks Feb 27 '15 at 1:19
5

I think you can use the trick.

set the break point in exit.

gdb ..

b exit

run ..

bt

so you can know where the main call the exit funciton

1

user/run/run.sh is presumably (given the name) a shell script that sets up things that the program needs to run. Likely things are setting environment variables and passing command line arguments. To set environment variables and command line arguments in GDB, use

set args = arg1 arg2
set env VAR1 = value1
set env VAR2 = value2

Read the shell script to see what it is actually doing.

  • I read run.sh to see what it does. Why do I need to set environment variables and set values like you listed in GDB? – user4352158 Feb 27 '15 at 2:54
  • @user4352158 So what does run.sh do? If it sets up environment variables or passes arguments, you need to do the same thing when you invoke the program under GDB. – Gilles 'SO- stop being evil' Feb 28 '15 at 17:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.