I recently flashed Firefox OS 2 on my ZTE Open C, and since then, it is impossible for me to do remote debugging.
I use the following command to forward the required stuff via adb :
adb forward tcp:$port localfilesystem:/data/local/debugger-socket
Where $port is usually 6666, but no other port number works.
I checked for /data/local/debugger-socket via ls in adb shell, but the socket isn't listed.
I enabled remote debugging on my phone, so the problem is elsewhere.
Related
I've been following this guide https://medium.com/#pellea/using-adb-with-wsl2-7aebbb070a47 and so far have gotten to the point where WSL2 can see the emulator(s) running on Windows through Android Studios -> AVD manager. For example, on both Windows and WSL2, adb devices correctly shows:
List of devices attached
emulator-5554 device
However, when I go to my expo app and try to launch the Android emulator, I get the following error message:
Couldn't start project on Android: could not connect to TCP port 5554: Connection refused
This is after I've tried the following:
exporting ADB_SERVER_SOCKET=tcp:<MY IP>:5037 in my WSL2 profile(s)
Unblocking WSL2 vEthernet connections from my Windows firewall via (from the above link)
Set-NetFirewallProfile -DisabledInterfaceAliases "vEthernet (WSL)"
I've portforwarded 5554 from Windows to WSL2, as well as 5037 (from 0.0.0.0 to 127.0.0.1):
$WSL_CLIENT = bash.exe -c "ip addr show eth0 | grep -oP '(?<=inet\s)\d+(\.\d+){3}'";
$WSL_CLIENT -match '\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}';
$WSL_CLIENT = $matches[0];
iex "netsh interface portproxy add v4tov4 listenport=5554 listenaddress=127.0.0.1 connectport=5554 connectaddress=$WSL_CLIENT"
The ports are as follows:
netsh interface portproxy show all
Listen on ipv4: Connect to ipv4:
Address Port Address Port
--------------- ---------- --------------- ----------
127.0.0.1 8081 172.25.38.171 8081
0.0.0.0 5037 127.0.0.1 5037
127.0.0.1 5554 172.29.149.0 5554
Just had the same issue with Expo.
Here is what fixed it for me:
Check for a process that uses port 5555 (Terminal)
netstat -ano | findstr 5555
Kill the process using its ID (PowerShell)
Stop-Process -ID [PROCESS_ID] -Force
Then it started working.
I had the exact same problem, but with a different setup (using Expo with the Metro bundler on a Mac). I worked around it by trying different virtual device images. Maybe the same can help you.
The virtual device that works with me so far is the one selected in this screenshot: https://i.stack.imgur.com/CFTJ0.png. The other two in the screenshot have the same problem. I don't really know the actual reason, must be something with port access with those other emulated devices.
Image details:
Name: 4 WVGA (Nexus S) API 29
API: 29
Target: Android 10.0 (Google APIs)
CPU/ABI (x86)
I'm sure other images work as well (or configuring the others somehow), i just haven't tried many more because it takes so long and they're so big.
Did you try to map port 5554 to Windows IP instead? (or localhost). The Android emulator is running on Windows, not WSL2, so the port proxy should be from WSL2 to Windows, not backwards.
Have you already solved it in another manner?
I am a total newbie and trying to debug an application which should receive a binary via TCP. When I launch it, it begins to listen several ports, I execute cat myfile | nc port_number in another terminal (apps terminal is busy) and the app runs. But I have no idea how to debug it in Qt creator. Everything I found on the Internet seems irrelevant to my problem.
I am having issues with serial and usb connection between host and target. Below is my setup. Both host and target do NOT have any serial (DB9) ports.
Host : Running windows + VMshare + Ubuntu
Target: Running linux kernel 3.19 . Has a MINI usb port which acts as a serial port, i think its ( CP210x uart to usb )
Connection 1 : Host ( USB to DB9 male-PL2303) + DB9 female to female + (DB9 male to USB) target.
Connection 2 : Host ( USB ) --cable-- (USB mini) Target
Host ( ubuntu VM ), can recognize the USB device (both connections types ) as /dev/ttyUSB0. The device does not show up on the windows device manager since VM takes over the device control.
Target boots into UEFI shell. I modify the syslinux.cfg file to append "kgdbwait kgdboc =ttyS0, 115200" to APPEND flag. Save the change ( press F2) then exit ( press F3 ). Boot into the image. Target now enters the kdb prompt with the following message
kgdb: Waiting for connection from remote gdb...
Entering kdb ( current= <64bit address>, pid 1) on processor 0 due to Keyboard Entry
Kgdb > _
on the host side, i do the following commands and below is error
root#ubuntu: cd /images
root#ubuntu: sudo gdb ./vmlinux
Reading symbols from ./vmlinux done.
(gdb)
(gdb) target remote /dev/ttyUSB0
Remote debugging using /dev/ttyUSB0
Ignoring packet error, continuing...
warning: unrecognized item "timeout" in "qSupported" response
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Bogus trace status reply from target: timeout
Experiments i tried
on Host i used " target remote /dev/ttyS0 " , still same issue
Tried different cables in each connection ( 1 and 2 ) mentioned above
on Target removed the edit in the syslinux.cfg file in UEFI shell, booted the image and entered kgdb using "echo g > /proc/sysrq-trigger"
All kernel configuration related to KGDB* , KGDB_SERIAL*, KGDB_USB* are enabled
all available baud rates
Questions
If i use "kgdbwait kgdboc=ttyUSB0, 115200" instead of " kgdbwait kgdboc=ttyS0, 115200" the target does NOT halt. When the target boots up fully to login prompt, i can see the device is recognized as ttyUSB0 when using connection 1. However as it does not stop does that mean, KGDB using USB does not work ? or for USB debug , i need to use direct USB--USB wire ( connection 3 ) ?
does syslinux.cfg support USB debug? becuase there is a SERIAL flag which has value" 0, 115200 " where 0 refers to ttyS0. syslinux documentation does not have any values for USB type device.
using connection 2, why am i seeing the timeout and packet error issues
occasionally with connection 2, when i execute " target remote /dev/ttyUSB0 " on the host, i notice junk characters on the target. So there is some communication happening, so tried different baud rates still same issue. Does this indicate anything inherently wrong with my setup?
In many online forums/ documents i do not see the "entering kdb due to keyboard entry" when the kernel enters kdb prompt. is this unusual?
The setup of remote kgdb debug is a bit tedious. There are several prerequisites/limitations for the kgdb to work. I will try to break it down.
You have to prepare two machines in this setup.
HOST: Where the agent-proxy & GDB installed.
TARGET: The Linux system being debugged.
Connection Setup
[Host /dev/ttyUSB0] USB to Serial --------- COM port [Target /dev/ttyS0]
On the TARGET side, it's not possible to use the USB interface with kgdb. This is because all the USB-Serial driver (CP210x, PL2303, ...etc) did not implement the polling hook. You have to connect the COM port with a serial cable directly. It is ok to use the USB interface on the HOST side. Since it is a serial connection, you have to use a USB-to-Serial converter and install the proper driver on HOST.
Set the proper baud rate on both sides:
[Target] stty -F /dev/ttyS0 115200
[Host] stty -F /dev/ttyUSB0 115200
Make sure the serial connection works on both direction. You can use:
[Host] cat /dev/ttyUSB0
[Target] echo 'from TARGET to HOST' > /dev/ttyS0
[Target] cat /dev/ttyS0
[Host] echo 'from HOST to TARGET' > /dev/ttyUSB0
You should see the messages on both side of machine. If not, there might be some problems on the cable or driver.
Compile Kernel
Enable KGDB* , KGDB_SERIAL*, KGDB_USB*, DEBUG_INFO, DEBUG_INFO_DWARF4, MAGIC_SYSRQ in the kernel config. Compile and install on the TARGET.
The main purpose here is to enable KGDB feature & preserve debug information in vmlinux.
agent-proxy Setup
agent-proxy acts as a proxy for the TARGET's serial port. It splits up the serial port for multiplexing. One for primary console I/O, the other for GDB session. Thus, we can work on both simultaneously. You should run the agent-proxy on HOST machine.
git clone http://git.kernel.org/pub/scm/utils/kernel/kgdb/agent-proxy.git
cd agent-proxy ; make
./agent-proxy 5550^5551 0 /dev/ttyUSB0,115200
This will redirect:
TARGET's console to HOST:5550
TARGET's kgdb listening port to HOST:5551
Start To Debug
First, open the primary console:
[Host] telnet localhost 5550
Entering the kdb mode, either by:
[Target] echo ttyS0,115200 > /sys/module/kgdboc/parameters/kgdboc
[Target] dmesg | tail
(you should see KGDB: Registered I/O driver kgdboc, otherwise it failed)
[Target] echo g >/proc/sysrq-trigger
Or, by adding the following kernel parameters in TARGET's bootloader (for early kernel debug):
console=tty0 console=ttyS0,115200 kgdbwait kgdboc=ttyS0,115200
The TARGET machine will halt immediately once it breaks into the kdb.
At the same time, you will see a kdb prompt on the primary console:
....
Entering kdb (current=0xcb846c80, pid 2301) on processor 3 due to Keyboard Entry
[3]kdb>
Type kgdb then enter. The TARGET is now pending for remote GDB's connection. We will connect it from the HOST.
Host> gdb vmlinux
(gdb) target remote localhost:5551
Remote debugging using localhost:5551
kgdb_breakpoint () at kernel/debug/debug_core.c:1072
1072 wmb(); /* Sync point after breakpoint */
(gdb)
Enjoy your kernel debugging!
I have a C++ application that uses ssh to summon a connection to the server. I find that sometimes the ssh session is left lying around long after the command to summon the server has exited. Looking at the Centos4 man page for ssh I see the following:
The session terminates when the command or shell on the remote machine
exits and all X11 and TCP/IP connections have been closed. The exit
status of the remote program is returned as the exit status of ssh.
I see that the command has exited, so I imagine not all the X11 and TCP/IP connections have been closed. How can I figure out which of these ssh is waiting for so that I can fix my summon command's C++ application to clean up whatever is being left behind that keeps the ssh open.
I wonder why this failure only occurs some of the time and not on every invocation? It seems to occur approximately 50% of the time. What could my C++ application be leaving around to trigger this?
More background: The server is a daemon, when launched, it forks and the parent exits, leaving the child running. The client summons by using:
popen("ssh -n -o ConnectTimeout=300 user#host \"sererApp argsHere\""
" 2>&1 < /dev/null", "r")
Use libssh or libssh2, rather than calling popen(3) from C only to invoke ssh(1) which itself is another C program. If you want my personal experience, I'd say try libssh2 - I've used it in a C++ program and it works.
I find some hints here:
http://www.snailbook.com/faq/background-jobs.auto.html
This problem is usually due to a feature of the OpenSSH server. When writing an SSH server, you have to answer the question, "When should the server close the SSH connection?" The obvious answer might seem to be: close it when the server-side user program started by client request (shell or remote command) exits. However, it's actually a bit more complicated; this simple strategy allows a race condition which can cause data loss (see the explanation below). To avoid this problem, sshd instead waits until it encounters end-of-file (eof) on the pipes connecting to the stdout and stderr of the user program.
#sienkiew: If you really want to execute a command or script via ssh and exit, have a look at the daemontool of the libslack package. (Similar tools that can detach a command from its standard streams would be screen, tmux or detach.)
To inspect stdin, stdout & stderr of the command executed via ssh on the command line, you can, for example, use lsof.
# sample code to figure out why ssh session does not exit
# sleep keeps its stdout open, so sshd only sees EOF after command completion
ssh localhost 'sleep 10 &' # blocks
ssh localhost 'sleep 10 1>&- &' # does not block
ssh localhost 'sleep 10 & lsof -p ${!}'
ssh localhost 'sleep 10 1>&- & lsof -p ${!}'
ssh localhost 'sleep 10 1>/dev/null & lsof -p ${!}'
ssh localhost 'sleep 10 1>/dev/null 2>&1 & lsof -p ${!}'
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.