Status Update
Comments
sh...@google.com <sh...@google.com>
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.
ki...@gmail.com <ki...@gmail.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".
di...@gmail.com <di...@gmail.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;
}
ag...@gmail.com <ag...@gmail.com> #5
nh...@gmail.com <nh...@gmail.com> #6
ba...@gmail.com <ba...@gmail.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
am...@gmail.com <am...@gmail.com> #9
yeah, i missed that change from ps1 to ps2. i think we should change that back.
to...@gmail.com <to...@gmail.com> #10
kn...@gmail.com <kn...@gmail.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.
Description
(adb shell sleep 60 && echo this shouldn't happen) & sleep 1; adb tcpip 5555
returns zero instead of failure (ssh returns 255 in this scenario, I think).