This is a similar question to sublimegdb can not stop in the breakpoint but nobody answers that one so I decided to open a new question.
I just installed sublimeGDB plugin in my sublime text 3 and set a breakpoint successfully by pressing F9. When I pressed F5 to run, the program didn't stop at the breakpoint -- it just finished running while the GDB view showed up for about 0.5 sec then disappeared.
Here's some output in my console view:
Will write debug info to file: stdout
Running: gdb --interpreter=mi ./ex8
In directory: //Users//jimmy/workspace
Process: <subprocess.Popen object at 0x1037a1110>
pty: 41, tty: None, name: /var/folders/m2/7h27qgr17v1bqyphh7wq6tpw0000gn/T/tmpnvs3afgdb_stdout: broken pipe
GDB session ended
gdb_stderr: /bin/sh: gdb: command not found
gdb_stderr: broken pipe
gdb_stderr: /bin/sh: gdb: command not found
This says: sublime ran /bin/sh, and asked it to run gdb, but no program called gdb was found on the PATH.
It must be that either:
you don't have GDB installed on your system at all, or
it is installed somewhere, but it's not on whatever PATH the sublime invokes /bin/sh with.
Related
I am debugging a program using valgrind and gdb. However I terminate those debugging sessions in a barbaric way… Is it really how it is meant to be done ?
Setting up the debugging session
Following the instructions from the official valgrind website I do the following to run the program :
I run valgrind by entering
valgrind --tool=memcheck --vgdb=yes --vgdb-error=0 ./prgm.run
From another terminal session, I run gdb using
gdb ./prgm.run
I connect gdb to valgrind
(gdb) target remote | vgdb
I run the program from gdb CLI
(gdb) c
So far so good : the program runs in both terminals (the one used for valgrind and the one used for gdb). Then valgrind finds an error, for instance an invalid read, and the program execution is paused.
Terminating the session
At that point, I want to fiddle with my code : perhaps fix something or comment/uncomment stuff from the program's source. As a consequence, the program needs to be compiled anew. A new binary is generated. Following that, I want to stop the on-going valgrind and gdb sessions (that were using the old binary) and start new valgrind and gdb sessions that will use the new binary.
To stop an on-going session, I quit gdb
(gdb) q
Sometimes valgrind notices that gdb is no longer there and quits too. But other times valgrind keeps going even-though no gdb process exist anymore…
In that case I kill the "memcheck-amd64-" process corresponding to my valgrind session. The number of that process is indicated in the valgrind messages e.g. 16195 in ==16195== Invalid read of size 8).
kill -9 16195
A regular kill is not enough : I need to use the -9 option.
I don't think invoking kill -9 is how it is meant to be done… Am I missing something ?
valgrind version : 3.10.1
gdb version : 7.7.1
you can also use the comand
(gdb)monitor v.kill
it was listed on monitor help on gdb.
Just use kill command or simply
k
to get rid of asking use set confirm off in .gdbinit file
The previous answers did not work for me, so I found this which did the trick.
(gdb) info inferiors Should list all inferiors in gdb session, find the one with 'remote target' as its name, take note of the number on the left of it (will be 1 if no other inferiors running in gdb)
(gdb) kill inferiors <number> Replace <number> with inferior number.
(gdb) quit
I have a few annoying warnings that appear when I start emacs:
$ /Applications/Emacs.app/Contents/MacOS/Emacs-x86_64-10_9 --
daemon=/tmp/green
Warning: arch-dependent data dir '/Users/build/workspace/Emacs-Multi-Build/label/mavericks/emacs-source/nextstep/Emacs.app/Contents/MacOS/libexec/': No such file or directory
starting ~/.emacs.d/init.el
ad-handle-definition: ‘tramp-read-passwd’ got redefined
ending ~/.emacs.d/init.el
Starting Emacs daemon.
How can I get rid of the tramp related warning and the "No such file" messages?
My setup is running:
emacs 25.1 mostly on -nw mode and daemon/client mode
osx 10.11.4
osx terminal with bash shell
This could happen if you have some environment variables set like EMACSPATH which if set needs to be a directory.
I'm using LLDB with the latest OS X toolchain (lldb --version says lldb-340.4.110).
I tried to debug executable which produces lots of output into stdout.
Previously it was possible to suppress output by redirecting it, e.g. to /dev/null.
But after latest OS X toolchain update it has started producing the following error:
(lldb) run >/dev/null
error: invalid JSON
Has something changed in LLDB in that area? Like adding some syntax for specifying stdin/stdout/stderr redirects. Can't find any clue in LLDB docs or mailing lists. Also I can suppose it is Apple-specific LLDB bug.
P.S.
I know that my problem can be temporary solved by running:
sudo lldb -w -n <executable> in separate terminal window, which will tell LLDB to wait for new process with the given name and then attach to that process. In that case I can run my executable in another terminal window with stdin redirected to /dev/null.
But I feel highly uncomfortable with that workflow, because stdout redirect just works in GDB on my Linux machine. Breaking the habits is always uncomfortable.
(lldb) process launch -o /dev/null -- <OTHER ARGUMENTS>
will do what you want. You can also make an alias to do this:
(lldb) command alias silent-run process launch -o /dev/null --
then:
(lldb) silent-run a b c
will run your program, redirect stdout to /dev/null, and pass a, b and c as arguments.
I would like to load my breakpoint commands from a file at startup using the '-s' flag to lldb, but it does not appear to accept the usual multiline input syntax of 'br command add' (a series of commands followed by 'DONE'). Is there a way to set a multiline breakpoint command from a script file?
I have a script file 'lldb.txt' with the following:
br set -n ptrace
br command add 1
register write pc `$pc + 42`
cont
DONE
And I'm running lldb as
lldb -s lldb.txt MyApp
The part from 'register' to 'DONE' does not work as it would from the lldb command prompt.
I'm running lldb on MacOS.
That's a bug in lldb. It will be fixed in the next lldb release.
I was trying to use gdb on a program earlier on a Linux 64-bit machine, and I ran gdb bomb (that's the program name), and within gdb, I simply typed in ran. It came back with the error /bin/bash: /home/imicrothinking/ics11302016004/lab2/bomb: No such file or directory During startup program exited with code 127.
I've dug around the net for a bit, and suggestions I've heard so far led to no concrete solutions, here's what I'm sure of so far:
I'm logged on as a root level user.
I haven't gone to the wrong directory.
The executable file definitely exists.
I'd welcome all suggestions.
maybe gdb cann't find your shell. so set the env var SHELL to your shell.
eg: export SHELL=/bin/bash
ref : http://www.linuxquestions.org/questions/linux-software-2/gdb-giving-wierd-error-169299/