I change post totally.
because I work in south korea army.
but south korea army internet computer is forbid upload file.
so I really upload my source code. but I can't .
so I try debug very very simple program with gdb.
but It is still not working.
my system is
Distributor ID: Ubuntu
Description: Ubuntu 14.04.3 LTS
Release: 14.04
Codename: trusty
in cloud IDE called "nitrous"
and g++ , gdb version is
g++ (Ubuntu 4.8.4-2ubuntu1~14.04) 4.8.4
GNU gdb (GDB) 7.8
I write very simple code : simple.cpp
#include <iostream>
int main(){
std::cout << "Hello World!" << std::endl;
return 0;
}
compile with "-g" and gdb execute
nitrous#ubuntu-108903:~/code$ g++ -g simple.cpp -o simple
nitrous#ubuntu-108903:~/code$ gdb simple
and set break main and run
Reading symbols from simple...done.
(gdb) break main
Breakpoint 1 at 0x400861: file simple.cpp, line 4.
(gdb) run
Starting program: /home/nitrous/code/simple
Hello World!
During startup program exited normally.
Even very simple helloworld program not work breakpoint.
just print out During startup program exited norally.
I set a break point, but it's not hit. What is problem?
The most likely problem is that your program terminates before reaching main. (A typical dynamically linked program will execute several hundred 1000s of instructions before reaching main.)
Run your program under GDB until GDB stops with SIGSEGV. Execute GDB where command. Observe that main is not on the stack.
Once you've confirmed that main is not on the stack, ask a different question (assuming you still don't understand the reason for crash).
I guess that gdb for some reason failed to set breakpoint. Try to run gdb with sudo.
Btw, could you run strace on generated elf and grep for ptrace? It should be something like follow strace -f -o syscall.txt gdb ./simple.out.
Related
I'm receiving this gdb error on any code I try to debug any program with gdb. Here's the simplest process that reproduces the error
Create a main.cpp file with this content:
int main(){
return 0;
}
Run g++ -g main.cpp
Run gdb a.out
Inside gdb set a break point at line 2 with break 2
In gdb run the program with run
Output:
Starting program: /tmp/test/a.out
During startup program exited normally.
This is all done with gdb on the command line. I've tried using g++ and gcc with the same result. I'm not really sure where to go from here.
gdb version = 9.2
g++ version = 9.3.0
EDIT: I figured out what is causing the issue, but not how to fix it. The issue seems to be something related to my SHELL variable. I'm currently using xonsh as my shell but when I set my SHELL environment variable back to /bin/bash everything works as expected. Is there anything I can do to fix this while using xonsh? Should I report this to xonsh, gdb, both or neither?
I'm currently using xonsh as my shell but when I set my SHELL environment variable back to /bin/bash everything works as expected. Is there anything I can do to fix this while using xonsh? Should I report this to xonsh, gdb, both or neither?
This might be your xonsh startup problem, or it might be xonsh problem, or it could be that xonsh doesn't do what GDB expects it to do.
Normally, GDB forks / execs $SHELL -c "/path/to/your/exe $args" and expects the $SHELL to exec your program (this is done so shell redirection still works under GDB).
Only after that exec will GDB start setting breakpoints, etc.
If you have some xonsh init-file, which e.g. causes xonsh to exec something else, things could go bad. So I suggest trying to remove any such ~/.xonshrc or whatever it's called file, and seeing whether that fixes the problem.
If it doesn't, it could be that xonsh e.g. forks and execs your binary in a child (grandchild of GDB) instead of doing it directly, or it could be that xonsh doesn't understand the -c ... syntax.
If you don't care about redirection, you could also ask GDB to not use $SHELL at all: set startup-with-shell off. Documentation.
I go this simple code to test my GDB ( GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.04) 7.11.1), my linux runs within docker, and the code is:
// hello.cc
#include <iostream>
int main() {
std::cout << "hello world!" << std::endl;
}
I compiled it with:
$ g++ -g -o out.a hello.cc
and debug it like:
(gdb) file out.a
(gdb) b main
Note: breakpoint 1 also set at pc 0x40084a.
(gdb) info b
Num Type Disp Enb Address What
1 breakpoint keep y 0x000000000040084a in main() at hello.cc:3
(gdb) r
hello world!
During startup program exited normally.
Why gdb not stopped on main?
Couple of reasons i can think of:
The gdb version i use is 7.0-0.4.16, and it worked as expected (ie., stopped at main). Probably it is related to version of gdb you have.
I am bit surprised on the info output in your gdb case. It showed the line number as '3' for breakpoint. Ideally it should be 4.
Ruling out the other two options mentioned above. Just observed that your linux is running on a docker. In this case, your test program is a process running on the docker and i assume gdb is invoked on native machine. You might need to attach the docker to gdb using lxc-attach.
Does anybody know how so use gdb in emacs?
I am using this command to create my program
/home/cdim/Local/gcc-4.9.2/bin/gfortran -ffree-form -g ./utests/test_gdb.f -o test_gdb
I am going to Emacs Tools then Debugger (GDB). I then click on the run button and nothing happens.
What does test_gdb do if you run it outside of gdb? If it sends no output to the screen then this (i.e., no output) is exactly what you will see when you run it inside of gdb - if you have set no breakpoints. Did you set a breakpoint? And how much nothing happens when you click run? Even if test_gdb produces no output, if all is well you should still see gdb display a notification like
[Inferior 1 (process 12345) exited normally]
Consider test.f:
Program p
Integer :: i = 1
Print *, i
End
I would compile this with gfortran -ffree-form -g -ggdb test.f -o test_gdb.
(From https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/Debugging-Options.html#Debugging-Options:
-ggdb
Produce debugging information for use by GDB. This means to use the most expressive format available (DWARF 2, stabs, or the native format if neither of those are supported), including GDB extensions if at all possible.
)
Then, as you said, go to Tools -> Debugger (GDB) (or issue M-x gdb) in emacs and make sure the gdb invocation is using the full path to the executable, e.g. Run gdb (like this): gdb -i=mi /foo/bar/test_gdb. Hit return in that minibuffer.
Now, set a breakpoint in the new *gud-test_gdb* buffer:
(gdb) break p
Breakpoint 1 at 0x4007e1: file test.f, line 3.
Then go to menu entry Gud -> Run.
Esc+x then entern gdb ... and input your application file. it will start gdb in emacs
I solved problem by moving to Trisquel 7.0. Might have been a setup problem.
I seem to have some kind of multithreading bug in my code that makes it crash once every 30 runs of its test suite. The test suite is non-interactive. I want to run my test suite in gdb, and have gdb exit normally if the program exits normally, or break (and show a debugging prompt) if it crashes. This way I can let the test suite run repeatedly, go grab a cup of coffee, come back, and be presented with a nice debugging prompt. How can I do this with gdb?
This is a little hacky but you could do:
gdb -ex='set confirm on' -ex=run -ex=quit --args ./a.out
If a.out terminates normally, it will just drop you out of GDB. But if you crash, the program will still be active, so GDB will typically prompt if you really want to quit with an active inferior:
Program received signal SIGABRT, Aborted.
0x00007ffff72dad05 in raise (sig=...) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
64 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
in ../nptl/sysdeps/unix/sysv/linux/raise.c
A debugging session is active.
Inferior 1 [process 15126] will be killed.
Quit anyway? (y or n)
Like I said, not pretty, but it works, as long as you haven't toggled off the prompt to quit with an active process. There is probably a way to use gdb's quit command too: it takes a numeric argument which is the exit code for the debugging session. So maybe you can use --eval-command="quit stuff", where stuff is some GDB expression that reflects whether the inferior is running or not.
This program can be used to test it out:
#include <signal.h>
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
int main() {
if (time(NULL) % 2) {
raise(SIGINT);
}
puts("no crash");
return EXIT_SUCCESS;
}
You can also trigger a backtrace when the program crashes and let gdb exit with the return code of the child process:
gdb -return-child-result -ex run -ex "thread apply all bt" -ex "quit" --args myProgram -myProgramArg
The easiest way is to use the Python API offered by gdb:
def exit_handler(event):
gdb.execute("quit")
gdb.events.exited.connect(exit_handler)
You can even do it with one line:
(gdb) python gdb.events.exited.connect(lambda x : gdb.execute("quit"))
You can also examine the return code to ensure it's the "normal" code you expected with event.exit_code.
You can use it in conjuction with --eval-command or --command as mentioned by #acm to register the event handler from the command line, or with a .gdbinit file.
Create a file named .gdbinit and it will be used when gdb is launched.
run
quit
Run with no options:
gdb --args prog arg1...
You are telling gdb to run and quit, but it should stop processing the file if an error occurs.
Make it dump core when it crashes. If you're on linux, read the man core man page and also the ulimit builtin if you're running bash.
This way when it crashes you'll find a nice corefile that you can feed to gdb:
$ ulimit -c unlimited
$ ... run program ..., gopher coffee (or reddit ;)
$ gdb progname corefile
If you put the following lines in your ~/.gdbinit file, gdb will exit when your program exits with a status code of 0.
python
def exit_handler ( event ):
if event .exit_code == 0:
gdb .execute ( "quit" )
gdb .events .exited .connect ( exit_handler )
end
The above is a refinement of Kevin's answer.
Are you not getting a core file when it crashes? Start gdb like this 'gdb -c core' and do a stack traceback.
More likely you will want to be using Valgrind.
I'd like to have gdb immediately run the executable, as if I'd typed "run"
(motivation: I dislike typing "run").
One way is to pipe the command to gdb like this:
$ echo run | gdb myApp
But the problem with this approach is that you lose interactivity with gdb,
eg. if a breakpoint triggers or myApp crashes, gdb quits.
This method is discussed here.
Looking at the options in --help, I don't see a way to do this, but perhaps I'm missing something.
gdb -ex run ./a.out
If you need to pass arguments to a.out:
gdb -ex run --args ./a.out arg1 arg2 ...
EDIT:
Orion says this doesn't work on Mac OSX.
The -ex flag has been available since GDB-6.4 (released in 2005), but OSX uses Apple's fork of GDB, and the latest XCode for Leopard contains GDB 6.3.50-20050815 (Apple version gdb-967), so you are out of luck.
Building current GDB-7.0.1 release is one possible solution. Just be sure to read this.
I would use a gdb-script:
gdb -x your-script
where your-script contains something like:
file a.out
b main
r
afterwards you have the normal interactive gdb prompt
EDIT:
here is an optimization for the truly lazy:
save the script as .gdbinit in the working directory.
Afterwards you simply run gdb as
gdb
... and gdb automatically loads and executes the content of .gdbinit.
(echo r ; cat) | gdb a.out
The cat allows you keep typing after gdb breaks.
start command
This command is another good option:
gdb -ex start --args ./a.out arg1 arg2
It is like run, but also sets a temporary breakpoint at main and stops there.
This temporary breakpoint is deactivated once it is hit.
starti
There is also a related starti which starts the program and stops at the very first instruction instead, see also: Stopping at the first machine code instruction in GDB
Great when you are doing some low level stuff.
gdb -x <(echo run) --args $program $args