Im trying to attach DDD to gdb on a remote machine. I have configured rsh to not require a pass for my machine & username.
ddd opens with "rtx5:1234: not found" and a pop-up with "GDB could not be started". From calling ddd --host rtx5:2159 --trace --no-exec-window /home/murray/beer-process
# Running GDB (pid 2826, tty /dev/pts/1)...
# Current language: C/C++
# Searching "vsllib/ddd.vsl"...
# Trying "/home/murray/.ddd/vsllib/ddd.vsl"
# Trying "/usr/share/ddd-3.3.12/vsllib/ddd.vsl"
# Searching "vsllib/ddd.vsl"..."/usr/share/ddd-3.3.12/vsllib/ddd.vsl".
<- "sh: line 0: exec: rtx5:2159: not found\n"
# Running GDB (pid 2826, tty /dev/pts/1)...Exit 127.
The PID of GDB started by ddd from the trace logs are 4-digits. However, all the PIDs that I can see from the rtx(target) are 8-digit. I can not see gdb as a process yet the trace log indicates otherwise. Is the documentation out of date and I am invoking it incorrectly? How could I test if ddd is correctly rsh-ing?
I have addressed the caveats of the docs 2.4.1:
Beer-process binary is in the home dir of my username on the target.
Checked the path of gdb in /usr/bin/gdb
rtx5 does not have xterm therefore include --no-exec-window flag
Thanks in advance
TLDR: Had a firewall on the host interfering only with ddd's rsh connection. I also had to substitute "rtx5" for "'rsh rtx5'". It wont find the program I pass it, even though its in the home directory of the remote target. I can however use ddd-gui to find, load, and debug it.
I could rsh to rtx5 without a password, then call gdb.
I could not do "rsh rtx5 gdb" and have gdb start. This is due to rsh. When rsh is called without a command it operates out of 514. If rsh in called with a command it communicates and attempts to move to a different port number. This is where my firewall was blocking it.
Wireshark showed me from local to target after rsh connection:
destination unreachable (host administratively protected)
ddd still has issues primarily that I can not load a binary which is in my remote home directory. This extends problem extends to attaching to running processes on the remote host. In both cases I can load/connect via the gui once the connection is established.
Furthermore I have to call ddd with 'rsh ' prepended to the remote-host name. This seems wrong. I'll update when I have more.
Related
I have the newest (2020.3 EAP ATM) version of CLion and I currently use it to remote debug a program on an embedded target (linux-mipsel).
Everything works as expected, after a bit of configuration, using self-built cross-toolchain and gdbserver.
My only problem is hitting the "red square" to stop execution will neither kill the running program nor gdbserver itself.
This means next iteration of edit-compile-debug cycle I will have two copies of both (I can get more, if I insist) which will not work as each tries to open the same resources (e.g.: a serial port) concurrently.
I have to manually log into target and kill the offending processes.
Am I missing something, is it a known bug or what?
Small update:
gdbserver is actually killed (does not show in ps ax) but underlying program (debugee) is still there. I am unsure why I was convinced otherwise, my bad.
This is a known issue and will hopefully be fixed soon.
Here is the link to the youtrack issue: https://youtrack.jetbrains.com/issue/CPP-20346
You could try the suggested workarounds:
Add pre-deploy configuration which kills running instances of the program
Follow the instructions for the gdb configuration in the comments:
GDB Server: /bin/bash
GDB Server args: -c "gdbserver :1234 /home/pi/myapp; pkill -e myapp"
The second config did not work for me, so I added the execution of an external tool where I run in /bin/bash the command -c "pkill -e myapp || true". The true is mandatory to avoid errors if the program is not running.
I have been trying to debug my xv6 locally (It is a 32-bit code). But I am working on a 64 bit machine and my gdb is 64 bit. Whenever I type
make gdb
I encountered the following error
+ target remote localhost:26000
.gdbinit:23: Error in sourced command file:
localhost:26000: Connection timed out.
(gdb) target remote localhost:26000
localhost:26000: Connection timed out.
I have a .gdbinit file. I have the following line in it
target remote localhost:26000
It's returning an error at this line. I initially thought it is because of 32-bit architecture of my machine. But if I go to some other directory and type the same message in the gdb console I am receiving the same error. I can't actually understand why it should connect to localhost(i.e what is need of a server here? ) as GDB is a normal GNU debugger right? and what is the reason for its failure in the above case?
Thanks in advance
Your question doesn't make any sense (to me).
As far as I can tell, you are asking: "why does GDB try to connect to localhost:2600".
The answer is: because you asked GDB to do so with the target remote localhost:26000 entry in your ~/.gdbinit.
Update:
I am asking what does that command do?
It instructs GDB to perform remote debugging, and to connect to gdbserver listening on the given port.
In general, you should never put anything into your ~/.gdbinit (or any other initialization file) that you don't understand. Doing so is akin to to taking an unknown object (a gun), putting it to your head, and squeezing a little lever on the side (a trigger).
and executing it giving me the above error so can you please say what is the error? and how to resolve it
Just delete the command (and any other commands that you don't know the meaning of) from ~/.gdbinit.
I've just solved the same problem u described. U can have a look at the GNUmakefile to search the port number your gdb-qemu attempted to connect to. In my GNUmakefile, the port number is
# try to generate a unique GDB port
GDBPORT := $(shell exprid -u% 5000 + 25000)
So when I try to run sudo make gdb-qemu, I got the result as follows:
qemu-system-i386 -drive file=obj/kern/kernel.img,index=0,media=disk,format=raw -serial mon:stdio -gdb tcp::25000 -D qemu.log -S
But when I run another terminal to run sudo make gdb, I got the result:
Type "apropos word" to search for commands related to "word".
+ target remote localhost:26000
The port number didn't match.
So by simply modify the port number in the GNUmakefile to 26000, we can get the ideal results.
Hope it's helpful :)
I had ever met the same problem as you. I had been troubled by this problem for hours.
But this problem is so easy.Please excute the following commands .
make qemu-gdb
make gdb (in another terminal.)
The reason for this problem is that when you execute the make gdb command, you end the execution of the make gdb .So the qemu server connection timed out .
In the picture, we can't alse find the infomation like remote gdb port...
You should change the port in the .gdbint file. It tells GDB which port to detach. I solved this problem in this way.
I'm having a problem debugging a command line program on OS X. I've used this same source file with the same g++ command line hundreds of times to test things with the Crypto++ library.
Under GDB, I get the following after loading the EXE:
$ gdb ./cryptopp-test.exe
...
(gdb) r
Starting program: /Users/jwalton/cryptopp-test.exe
Unable to find Mach task port for process-id 42811: (os/kern) failure (0x5).
Under LLDB, I get the following:
$ lldb ./cryptopp-test.exe
Current executable set to './cryptopp-test.exe' (x86_64).
(lldb) r
error: initial process state wasn't stopped: exited
I've recompiled the program a few times, and I can't get it to run under a debugger. I'm getting a segfault when trying to run outside the debugger too, so that may be a symptom here also.
OS X is 10.8.5, and Xcode is 5.1.1 (5B1008). Everything is fully patched. The only thing to change recently is signing up for a developer account, which is broken thanks to Apple's DRM crap. I can't seem to get any of it to work with Xcode or the command line even though Roots and Certificates are in my Keychain. But this program does not use code signing.
What is causing the initial process state wasn't stopped: exited error, and how do I fix it?
The errors that you have received are usually a direct correlation of a codesigning issue, not with your executable, but with gdb and lldb themselves.
You have a couple of options:
Launch gdb or lldb as sudo (which ignores the codesign req to run executables)
Create a codesigning certificate for gdb or lldb in Keychain.app
Obviously the first option is quickest, but probably should be avoided as it opens up the possibility of bad things happening with elevated permissions.
With option #2 you can likely get gdb or lldb properly working by doing this:
Launch /Applications/Utilities/Keychain Access.app
Select the Keychain Access -> Certificate Assistant -> Create a Certificate...
Choose a name for the new certificate (for example lldb-cert or gdb-cert)
Set Identity Type to Self Signed Root
Set Certificate Type to Code Signing
Select the Let me override defaults option
Continue until the "Specify a Location For The Certificate" screen appears
Set Keychain to System and Continue
In the view showing your certificates, double-click on the one just created and then set "When using this certificate" to "Always Trust"
In Terminal:
codesign -f -s "gdb-cert" /path/to/gdb (or) "lldb-cert" /path/to/lldb
You might have to restart for this to effectively take hold.
There are more concise instructions here for gdb and here for lldb on the codesigning process.
I have:
A proprietary prototype ARM board (Cortex-M3 based) with eCos OS
The board has the programmed RedBoot bootloader
Serial line (RS-232)
GDB debugger for ARM (arm-eabi-gdb)
Host OS is Windows/Cygwin and/or Linux (actually, doesn't matter)
Problem: GDB debugger cannot connect to the target over the serial line.
What I want: is to sniff the packets of the GDB remote protocol in order to undestand whether the GDB stub on the target is alive and operating.
Details: RedBoot has an option to pass the target's control to the built-in GDB stub. I know that the RedBoot is alive, I can connect to it and send it commands over the serial line. The RedBoot manual says that the switch to the GDB stub can be made by typing $ or + symbols (which are actually the prefixes of the GDB remote protocol packets). It seems to work for when I send those symbols the terminal dies. But I'm not sure if the RedBoot was compiled with the GDB stub support (don't ask me why :-)).
Then, when I try to connect to the board with my GDB debugger I get the following picture (on Windows):
(gdb) target remote COM3
Remote debugging using COM3
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
The port is correct, the baudrate as well. Actually the same output I get if I try to do the same with another serial port which is not connected with anything.
What I want to know is does GDB stub send back anything or not?
Intuitively I thought that probably
set verbose on
would help, but GDB manual says it has very a limited effect and my case is beyond it.
May be it is possible to compile GDB debugger with a macro which enables debug logging?
What I want to know is does GDB stub send back anything or not?
Do this (before target remote):
(gdb) set debug remote 1
A while ago I changed my personal operating system to linux and my development enviroment to KDevelop.
However debugging c++ projects is still not working as it should.
My KDevelop version is 4.2.2 (I installed it through package management)
Every time I hit the "debug button" the application is starting with the console message
warning: GDB: Failed to set controlling terminal: Operation not permitted and debugging functionality is not available.
Any ideas welcome.
(If you need additional information don't hesitate to ask)
I also had this problem, but I use gdb in KDevelop sparsely enough that hadn't bothered me yet. Here's my log of trying to fix it:
Grepping through the GDB 7.3.1 source code reveals that this message is printed when GDB tries to set its master TTY to a newly-created pseudo-tty (see gdb/inflow.c, lines 683-740). In particular, a call to ioctl with request TIOCSCTTY fails with a permissions error.
With this in mind, I took a look at the Linux kernel source code to see what could cause a failure. A bit of searching shows that it will eventually degenerate into a call to tiocsctty(). The comment from tiocsctty that is important here:
/*
* The process must be a session leader and
* not have a controlling tty already.
*/
Since the only other reason it can fail with EPERM is if the tty that GDB creates is actually a controlling tty for another process (which seems highly unlikely), I thought it reasonable to assume that GDB is not a session leader. Fair enough, it's launched by KDevelop after all!
So: I tried not launching the GDB session in an external terminal, and it works. Problem narrowed down.
Originally, the external terminal line was set to konsole --noclose --workdir %workdir -e %exe. Changing this to terminator -e %exe made a slight difference: KDevelop warned me that
GDB cannot use the tty* or pty* devices.
Check the settings on /dev/tty* and /dev/pty*
As root you may need to "chmod ug+rw" tty* and pty* devices and/or add the user to the tty group using "usermod -G tty username".
I checked my permissions; my user was part of the tty group and all relevant files were readable and writable.
Grepping through the KDevelop source code reveals how KDevelop actually sets up the terminal. It runs the shell script
tty > FIFO_PATH ; trap "" INT QUIT TSTP ; exec<&-; exec>&-; while :; do sleep 3600;done
and then sets up GDB to use the terminal device it reads from FIFO_PATH. (My name, by the way, not the one that KDevelop uses.) The problem (as best I can tell) is that gdb is not launched as a child of the shell script, and thus cannot use it as its main tty.
I'm not feeling up to patching KDevelop to make this work properly as of yet (or finding what actually caused this to stop working in the first place . . .), so the best I can suggest at the moment is to simply not use an external terminal for debugging purposes.
Good luck! I'll update if I find anything useful.
As Arthur Zennig said, for more information, you need to do something
Firstly, you need to create the Terminal profile
Secondly, open Launch Configurations, fill info such as the image below
Good luck!
In case you got the error:
"Can't receive konsole tty/pty. Check that konsole is actually a
terminal and that it accepts these arguments"
RUN > CONFIGURE LAUCHERS > (See picture below. My project name was "loops")
What worked for me was to uncheck checkbox "Use External Terminal". Found the in the "Compiled Binaries" Tab.