Status Update
Comments
se...@gmail.com <se...@gmail.com>
dn...@google.com <dn...@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.
se...@gmail.com <se...@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".
se...@gmail.com <se...@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;
}
se...@gmail.com <se...@gmail.com> #5
se...@gmail.com <se...@gmail.com> #6
uc...@google.com <uc...@google.com>
xa...@google.com <xa...@google.com> #7
se...@gmail.com <se...@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
se...@gmail.com <se...@gmail.com> #9
yeah, i missed that change from ps1 to ps2. i think we should change that back.
se...@gmail.com <se...@gmail.com> #10
xa...@google.com <xa...@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.
Description
Build: AI-203.7717.56.2031.7784292, 202110010236,
AI-203.7717.56.2031.7784292, JRE 11.0.10+0-b96-7249189x64 JetBrains s.r.o, OS Windows 10(amd64) v10.0 , screens 1920.0x1080.0
AS: Arctic Fox | 2020.3.1 Patch 3; Kotlin plugin: 203-1.5.31-release-550-AS7717.8; Android Gradle Plugin: 7.0.3; Gradle: 7.0.2; Gradle JDK: version 11.0.10; NDK: from local.properties: (not specified), latest from SDK: (not found); LLDB: pinned revision 3.1 not found, latest from SDK: (package not found); CMake: from local.properties: (not specified), latest from SDK: (not found), from PATH: (not found)
IMPORTANT: Please read