Status Update
Comments
sh...@google.com <sh...@google.com> #2
What do you see when you do: `adb reboot && adb wait-for-device` (this is a commonly used pattern and will continue to be supported - adb will block until the device initializes).
adb usage (for most cases, including `devices`) does *not* require root (root would be needed only when you need to do specialized tasks like push. The behavior of `adb devices` should not be contingent on root.
You might also want to see what gets reported (in response to `adb devices`) after doing `adb unroot`.
If there's still any residual questions, I'll need to look at the host/server logs (and possibly the device logs) - you can attach those to this bug.
en...@google.com <en...@google.com> #3
Same behavior is observed after running adb root when root is not already acquired.
note that adb root
re-starts the adbd running on the device. so the common element here -- if you're all talking to the same device(s) -- might be "there's a problem with the usb stack on the devices we're talking to, that means they don't come back when adbd restarts".
da...@sonos.com <da...@sonos.com> #4
I have the same issue and I've actually found the problem and have a tested fix.
In usb_linux.cpp, where the following code is:
unsigned char length = bufptr[0];
unsigned char type = bufptr[1];
A corsair usb device results in a type
and length
of both 0, even though all processing in the code is correct. It has several good descriptors, eventually followed by a length and type of 0, before bufptr gets to the full descriptor length. Therefore, this code loops indefinitely, and plugging in new devices is never found.
The fix is simple:
@@ -292,6 +292,9 @@ static void find_usb_device(const std::string& base,
device->iSerialNumber, zero_mask, max_packet_size);
break;
}
+ } else if (length == 0) {
+ D("interface descriptor has wrong size");
+ break;
} else {
bufptr += length;
}
ju...@sonos.com <ju...@sonos.com> #5
ju...@sonos.com <ju...@sonos.com> #6
da...@sonos.com <da...@sonos.com> #8
Thanks for the fix! This is great news.
The fix from type
is explicitly 0. It can still potentially lead to an infinite loop should some device contain a descriptor with a non-zero type
and a zero length
. While this fixes my problem, I'd still be weary of leaving this potential infinite loop in.
Thanks again
en...@google.com <en...@google.com> #9
yeah, i missed that change from ps1 to ps2. i think we should change that back.
sh...@google.com <sh...@google.com> #10
en...@google.com <en...@google.com> #11
a zero-length descriptor will always cause this code to go into an infinite loop (because we only handle one type
, and that's above this code --- if we could handle the type, we've already done so). it's never going to be useful for the adb server to hang if something's reporting a bad descriptor, so we should always break.
sh...@google.com <sh...@google.com>
ne...@gmail.com <ne...@gmail.com> #12
Buenas tardes
aa...@gmail.com <aa...@gmail.com> #13
si...@gmail.com <si...@gmail.com> #14
hu...@gmail.com <hu...@gmail.com> #15
Marked as fixed
ja...@gmail.com <ja...@gmail.com> #16
fixed
Description
$ adb --version
Android Debug Bridge version 1.0.41
Version 34.0.4-10411341
Installed as /usr/local/android/sdk-linux_x86/platform-tools/adb
Running on Linux 6.2.0-33-generic (x86_64)
$ adb devices
List of devices attached
<scrubbed> device
$ adb reboot
$ adb devices
List of devices attached
$ adb kill-server
$ adb devices
* daemon not running; starting now at tcp:5037
* daemon started successfully
List of devices attached
<scrubbed> device
For what it's worth, this is impacting a few of my co-workers, whom all have similar hardware / build environments.
Any information / debugging suggestions would be greatly appreciated. Thanks in advance.