I just finished setting an Espressif project in Eclipse but upon debugging using OpenOCD after following the instructions here, I'm getting the following error:
Error in final launch sequence:
Failed to execute MI command:
-target-select remote localhost:3333
Error message from debugger back end:
localhost:3333: Operation timed out.
Failed to execute MI command:
-target-select remote localhost:3333
Error message from debugger back end:
localhost:3333: Operation timed out.
localhost:3333: Operation timed out.
Does that mean port 3333 is either busy or doesn't exist?
Also, when I ran netstat in terminal, I didn't see a port with 3333. Could that be why?
There are two possibilities to get this error: openocd is not runing or it is busy.
you will see 3333 with netstat only if there is already a connection between openocd and gdb.
Since you dont see 3333 when runing netstat, most likely openocd did not start or it crashed.
run ps ax | grep openocd to make sure there is an openocd running.
Related
I trying to follow the instruction on connecting to valgrind using gdb.
Valgrind memcheck is starts properly and asks to connect using following gdb command:
target remote | vgdb --pid=53181
but when I run this command, I get an error
Remote communication error. Target disconnected.: Connection reset by
peer
what is my mistake?
It appears that error
Remote communication error. Target disconnected.: Connection reset by peer.
is general and may indicate invalid command as well. If you run in gdb
target remote | something
it will give you the same error message.
It appeared for me, that extra space after | symbol was excess.
Correct command was actually
target remote |vgdb --pid=53181
My GDB version is GNU gdb (Ubuntu 10.2-0ubuntu1~18.04~2) 10.2
I have a docker container running with -p 2000:2000, which is running a gdbserver on port 2000.
When trying to connect from my host machine through gdb I get the following:
(gdb) target remote localhost:2000
Remote debugging using localhost:2000
Ignoring packet error, continuing...
warning: unrecognized item "timeout" in "qSupported" response
Ignoring packet error, continuing...
Remote replied unexpectedly to 'vMustReplyEmpty': timeout
The application running in the docker container is written in C++, behind a fcgi (gdbserver :2000 spawn-fcgi -p 8000 -n ./myBinary)
Host
OS: osx
gdb version: 8.0.1 (installed with --with-all-targets)
Container
OS: ubuntu 14.04
gdb version: 7.7.1
Any help would be appreciated.
i meet the same question ，when i run my qemu ，and i want connect gdb with qemu inner gdbserver.
i do the follow job:
run qemu in system mode.
run gdbserver inside qemu
run gdb in Host computer and connect gdbservr inside gdb.
the software version are below:
QEMU emulator version 2.12.92
gdb 7.11.1
GNU gdbserver (GDB) 7.8
at first i cannot connect gdbserver,the error is
(gdb) target remote 192.168.240.136:1234
Remote debugging using 192.168.240.136:1234
Ignoring packet error, continuing...
warning: unrecognized item "timeout" in "qSupported" response
Ignoring packet error, continuing...
Remote replied unexpectedly to 'vMustReplyEmpty': timeout
i solve the problem by change to high level kernel when start start qemu. from vmlinux-2.6.32-5-4kc-malta to vmlinux-3.2.0-4-4kc-malta,then the command start qemu changed to below:
sudo qemu-system-mips -M malta \
-kernel vmlinux-3.2.0-4-4kc-malta \
-hda debian_squeeze_mips_standard.qcow2 \
-append "root=/dev/sda1 console=tty0" \
-net nic,macaddr=00:16:3e:00:01:01 \
-net tap \
-nographic
then the error was solved ,i can connect gdbserver with gdb.
the possible solve ways also include
bash setting
conflict
serial setting error
I used to the St-write to burn .bin to the STM32F4 and saw the message which I expected. Now, I hope to understand how GPIO init. Hence, I use OpenOCD and arm-none-eabi-gdb to do that. Here, it is my process.
$ minicom
$ openocd -f /opt/openocd/share/openocd/scripts/board/stm32f4discovery.cfg
$ arm-none-eabi-gdb main.elf
(gdb) target remote localhost:3333
(gdb) localhost:3333: Connection timed out.
How do I check the port of OpenOCD? Why does it occur timeout?
That certainly means that openocd did not start or that the port is busy.
Usually, you use :
openocd -f board/stm32f4discovery.cfg
You should check that your session is running.
Are you running a virtual linux machine on a windows host?
If so, you probably need to replace localhost with 10.0.0.2 (or whatever your windows IP is).
A good way to know, is to telnet to the openOCD address and port 4444 and see if you get the openOCD prompt, and can type a few commands.
I am trying to debug a device driver which is crashing the kernel on a Mac using a remote machine running gdb (trying to follow the instructions here). Both machines are connected to the same network by Ethernet (same router even, and both can access the network). I have also set nvram boot-args="debug=0x144" on the target and restarted.
I then load the kernel extension on the target as usual. On the host machine I start gdb like this:
$ gdb -arch i386 /Volumes/KernelDebugKit/mach_kernel
Once in gdb, I load the kernel macros and set up for remote attachment
(gdb) source /Volumes/KernelDebugKit/kgmacros
(gdb) target remote-kdp
(gdb) kdp-reattach 11.22.33.44
However, the last command then does not make a connection and I get an endless spool of
kdp_reply_wait: error from kdp_receive: receive timeout exceeded
kdp_transaction (remote_connect): transaction timed out
kdp_transaction (remote_connect): re-sending transaction
What is the correct way to get gdb connected to the target machine?
There are a number of ways to break into the target, including:
Kernel panic, as stated in your answer above.
Non-maskable interrupt, which is triggered by the cmd-option-ctrl-shift-esc key combination.
Code a break in your kernel extension using PE_enter_debugger(), which is declared in pexpert/pexpert.h
Halt at boot by setting DB_HALT (0x01) in the NVRAM boot-args value.
Additionally, you may need to set a persistent ARP table entry, as the target is unable to respond to ARP requests while stopped in the debugger. I use the following in my debugger-launch shell script to set the ARP entry if it doesn't already exist:
if !(arp -a -n -i en0 | grep '10\.211\.55\.10[)] at 0:1c:42:d7:29:47 on en0 permanent' > /dev/null) ; then
echo "Adding arp entry"
sudo arp -s 10.211.55.10 00:1c:42:d7:29:47
fi
Someone more expert could probably improve on my bit of shell script.
All of the above is documented in http://developer.apple.com/library/mac/documentation/Darwin/Conceptual/KernelProgramming/KernelProgramming.pdf.
The answer is simply to make sure the target has a kernel panic before you try to attach gdb from the host.
Does anyone know why I can't use Eclipse CDT to remotely debug a device when I manage it on the command-line with gdb using target remote command? I do get a warning when connecting, but other than that it seems to work fine.
With Eclipse I should have the correct settings and gdbserver informs me on the remote machine that a connection was establised but after that Eclipse gives an error: 'Launching Debug' has encountered a problem. The request failed: Target is not responding (timed out). Remote device also says "Killing inferior" (which I don't get with gdb). The error log shows nothing else either.
I am using the same process, binary and gdb executable in both cases and connecting to the same device & port. I'm using gdb 7.1 and the host is 64-bit Ubuntu Lucid.
I had same issue and found that iptables was generating issues.
Have you tried stopping or disabling your firewall? In case of iptables you have to do:
/etc/init.d/iptables stop
On the other hand, after you start your application (before connecting your debugger) have you checked the debug port availability through netstat?
#On linux
netstat -nap
#On windows
netstat -nab
Hope to help.