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.
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.
Background
I am currently trying to build an autonomous drone using ROS on my Rapsberry Pi which is running an Ubuntu MATE 16.04 LTS. Solving the Computer Vision problem of recognising red circles as of now.
Specific Problem
I am constantly getting the error I get in this question. To help me solve this, I have decided to use gdb. However, the command rosrun --prefix 'gdb run --args' zlab_drone vdstab does not seem to be working for me. zlab_drone is the name of the package and vdstab is the name of the executable I am trying to run. Since this is inside a ROS environment, I have grabbed the syntax from here, and used the suggestions in this question.
When I invoke this command, even with tui, I get a SIGSEGV and when I invoke list inside gdb itself, the program does not stay at a particular point and keeps listing a different line till it is out of range. This is quite a weird issue.
I managed to make it work without this issue earlier by using a different command, I reckon. I just cannot remember how I made it work last time.
Well, in the link you mentioned, it states clear that you should use either :
launch-prefix="xterm -e gdb --args" : run your node in a gdb in a separate xterm window, manually type run to start it
or :
launch-prefix="gdb -ex run --args" : run your node in gdb in the same xterm as your launch without having to type run to start it
So, it really looks like you missed an -ex as #ks1322 suggeseted in the comments or just type run to start the debug process.
I found out about this exclusive bug that relates to Raspberry Pi's solely. Basically the solution involves, as quoted by Peter Bennet:
There is a workaround. Start the program, then from another command
prompt or from an ssh remote login, use gdp -p xxxxx where xxxxx is
the process number. This works without crashing. If you need to debug
something that happens before you can get in from another command
prompt, add to the program a command that stops process at the
beginning of main, for example a call to gets, which will wait for you
to press enter before continuing.
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 am trying to debug Linux kernel with kvm vm. I am getting an error message "Remote 'g' packet reply is too long". My host is 64-bit and so is my vm.
My steps:
Start the VM with custom -kernel, -initrd and -append options.
Start gdb
Execute "set architecture i386:x86-64:intel"
Execute "add-symbol-file linux-3.0/vmlinux"
Execute "show arch" to verify its still "i386:x86-64:intel"
Execute "target remote localhost:1234"
Execute "continue"
Press Ctrl+C, I get the above message.
Has anyone faced this problem?
gdb doesn't work well against a cpu that switches between instruction sets at runtime. Wait for the kernel to leave early boot before connecting, and don't use qemu's -S flag.
I also faced same issue, I fixed it by modifying gdbstub.c (in qemu sources) to send 64bit registers always and hinting GDB that architecture is 64bit by passing set arch i386:x86-64
You can check the patch here:
Visit [URL no longer available]
I found a similar problem (& this question) connecting gdb very early in the boot process – as mentioned in other answers, gdb does not very much appreciate the size of registers changing out from under it. This problem can be seen by using set debug remote 1:
(gdb) set debug remote 1
(gdb) target remote localhost:1234
Remote debugging using localhost:1234
...
Sending packet: $g#67...Ack
Packet received: 000000000000000... <~600 bytes>
(gdb) until *0x1000 # at this address we'll be in a different cpu mode
...
Sending packet: $g#67...Ack
Packet received: 10000080000000000000000000000000800000c... <~1000 bytes>
...
Remote 'g' packet reply is too long: 1000008000000000000000000...
(gdb)
Patching gdb to resize its internal buffer when it sees a too-large packet
as found on this issue in the gdb bug tracker (and elsewhere), does indeed work around the problem, as does patching QEMU to only send 64-bit-sized packets. However, the latter solution breaks debugging in non-64-bit-modes, and it seems that the former fix could be incomplete:
It sounds quite wrong to be changing the target behind
GDB's back when GDB is already debugging it. Not just the size
of the g/G packets may change inadvertently, but the layout as well.
If the target description changes with your re-configuration, it
sounds to me like GDB should fetch/recompute the whole target
description. Today, I think that can only be done with a
disconnect/reconnect.
– https://sourceware.org/ml/gdb/2014-02/msg00005.html
The disconnect/reconnect workaround mentioned at the end of the post does appear to work:
(gdb) disconnect
Ending remote debugging.
(gdb) set architecture i386:x86-64
The target architecture is assumed to be i386:x86-64
(gdb) target remote localhost:1234
Remote debugging using localhost:1234
(gdb) info registers
rax 0x80000010 2147483664
rbx 0x0 0
...
I had accidentally omitted the binary name as an argument to gdb. So this worked for me.
$ gdb ./vmlinux
(gdb) target remote localhost:1234
And then got the Output :
Remote debugging using localhost:1234
0xffffffff81025f96 in default_idle ()
The debugger needs vmlinux so make sure you provide it. OP has a different problem, But my answer might help to those who forgot to provide argument to gdb and ended up with the same error message as OP.
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.