adb server crashes on startup and unable to communicate with some devices on macOS [404741058]

Assigned

Bug

Status Update

No update yet.

Description

ya...@gmail.com

created issue #1

Mar 19, 2025 05:40PM

Host: Mac Mini M4
OS: macOS 15.2 and 15.3 Sequoia
adb: 35.0.2-12147458

Devices: Samsung S20, S21+
Devices OS: Android 11
Firmware: RP1A.200720.012

Description: We are running into adb server crashes when certain devices are connected to a macOS host. The adb server doesn't even start. However, everything is fine when these devices are connected to a Windows host running the same adb server version. Everything also works as expected when some of the problematic devices are disconnected from the mac machines.

Logs

03-11 22:41:34.426 42535 89459648 I adb     : transport.cpp:1153 XXXXXXXXXX: connection terminated: libusb write failed
03-11 22:41:34.426 42535 89459648 E adb     : usb_libusb.cpp:177 usb read failed: status = 1
03-11 22:41:34.426 42535 89459627 I adb     : adb.cpp:177 XXXXXXXXXX: already offline
03-11 22:41:34.426 42535 89459627 I adb     : transport.cpp:836 destroying transport XXXXXXXXXX
03-11 22:41:35.130 42535 89459648 I adb     : transport.cpp:1153 XXXXXXXXXX: connection terminated: libusb write failed
03-11 22:41:35.130 42535 89459627 I adb     : adb.cpp:177 XXXXXXXXXX: already offline
03-11 22:41:35.130 42535 89459627 I adb     : transport.cpp:836 destroying transport XXXXXXXXXX
03-11 22:41:35.234 42535 89459627 W adb     : usb_libusb.cpp:660 libusb_cancel_transfer failed: LIBUSB_ERROR_NOT_FOUND
03-11 22:41:35.234 42535 89459648 F adb     : usb_libusb.cpp:155 Check failed: read_block->transfer

Troubleshooting

We upgraded adb server to 36.0.0 nightly build because we noticed the libusb backend was re-written and the crash went away. However, adb server was still unable to communicate with some of the devices mentioned above. See logs below (we turned libusb debugging on as well).

It looked like for some devices I/O would not work when using libusb_bulk_transfer(). We narrowed the issue to the following lines of code: https://cs.android.com/android/platform/superproject/main/+/main:packages/modules/adb/client/usb_libusb_device.cpp;l=470-478

Calling libusb_clear_halt() on startup during USB interface claim call is causing some devices to not communicate properly.

Digging through the libusb mailing list we found the following discussion https://sourceforge.net/p/libusb/mailman/libusb-devel/thread/1cc26359-d241-1061-4906-231ec0e28bab%40gmail.com/#msg38634913 . It seems that it's not recommended to call libusb_clear_halt() which calls ClearPipeStallBothEnds() on macOS unless an actual LIBUSB_ERROR_PIPE is encountered. Similar sentiment was found on github in these comments https://github.com/libusb/libusb/issues/1110#issuecomment-1090552757 and https://github.com/libusb/libusb/issues/1110#issuecomment-1090621211

This also confirms why everything is fine on Windows using the native backend. On Windows, the native backend doesn't appear to call ResetPipe().

Additionally, it looks like macOS NATIVE backend implementation is using the ADB_OSX_USB_CLEAR_ENDPOINTS environment variable to determine whether to call ClearPipeStallBothEnds() . Native backend on macOS didn't work well for us, it was quite unstable.

[ 1.726333] [01ba4c27] libusb: debug [libusb_claim_interface] interface 4
[ 1.726994] [01ba4c27] libusb: debug [get_endpoints] building table of endpoints.
[ 1.760376] [01ba4c27] libusb: debug [get_endpoints] interface: 4 pipe 1: dir: 0 number: 4
[ 1.770941] [01ba4c27] libusb: debug [get_endpoints] interface: 4 pipe 2: dir: 1 number: 6
[ 1.770999] [01ba4c27] libusb: debug [darwin_claim_interface] interface opened
[ 1.771003] [01ba4c27] libusb: debug [libusb_clear_halt] endpoint 0x86
[ 1.771005] [01ba4c27] libusb: debug [ep_to_pipeRef] converting ep address 0x86 to pipeRef and interface
[ 1.771007] [01ba4c27] libusb: debug [ep_to_pipeRef] pipe 2 on interface 4 matches
[ 1.771690] [01ba4c27] libusb: debug [libusb_clear_halt] endpoint 0x4
[ 1.771693] [01ba4c27] libusb: debug [ep_to_pipeRef] converting ep address 0x04 to pipeRef and interface
[ 1.771695] [01ba4c27] libusb: debug [ep_to_pipeRef] pipe 1 on interface 4 matches
03-16 22:17:21.075 44660 28986407 D adb     : usb_libusb_device.cpp:480 Claimed interface for XXXXXXXXXX, bulk_in = 0x86, bulk_out = 0x4
03-16 22:17:21.075 44660 28986407 D adb     : usb_libusb_device.cpp:497 Attached device XXXXXXXXXX
03-16 22:17:21.075 44660 28986407 D adb     : adb.cpp:328 Calling send_connect
03-16 22:17:21.075 44660 28986603 I adb     : usb_libusb.cpp:90 XXXXXXXXXX: read thread spawning
03-16 22:17:21.075 44660 28986603 D adb     : usb_libusb_device.cpp:133 LibUsbDevice Read()
03-16 22:17:21.075 44660 28986604 I adb     : usb_libusb.cpp:119 XXXXXXXXXX: write thread spawning
03-16 22:17:21.075 44660 28986407 D adb     : transport.cpp:573 XXXXXXXXXX: to remote: [CNXN] arg0=0x1000001 arg1=0x100000 (len=291) 686f73743a3a66656174757265733d73 host::features=s [truncated]
[ 1.772505] [01ba4ceb] libusb: debug [libusb_submit_transfer] transfer 0x156b047f0
[ 1.772519] [01ba4ceb] libusb: debug [ep_to_pipeRef] converting ep address 0x86 to pipeRef and interface
[ 1.772521] [01ba4ceb] libusb: debug [ep_to_pipeRef] pipe 2 on interface 4 matches
03-16 22:17:21.075 44660 28986407 D adb     : fdevent_poll.cpp:114 --- --- waiting for events
03-16 22:17:21.075 44660 28986407 D adb     : fdevent_poll.cpp:136 poll(), pollfds =  4(R) 7()
03-16 22:17:21.075 44660 28986604 D adb     : usb_libusb_device.cpp:99 Write A_CNXN payload=291
[ 1.772537] [01ba4cec] libusb: debug [libusb_submit_transfer] transfer 0x156a04790
[ 1.772549] [01ba4cec] libusb: debug [ep_to_pipeRef] converting ep address 0x04 to pipeRef and interface
[ 1.772551] [01ba4cec] libusb: debug [ep_to_pipeRef] pipe 1 on interface 4 matches
[ 1.772562] [01ba4ceb] libusb: debug [libusb_get_next_timeout] no URB with timeout or all handled by OS; no timeout!
[ 1.772566] [01ba4ceb] libusb: debug [libusb_handle_events_timeout_completed] another thread is doing event handling
[ 1.772584] [01ba4cec] libusb: debug [libusb_get_next_timeout] no URB with timeout or all handled by OS; no timeout!
[ 1.772588] [01ba4cec] libusb: debug [libusb_handle_events_timeout_completed] another thread is doing event handling
[ 1.812068] [01ba4c5e] libusb: debug [darwin_async_io_callback] an async io operation has completed
[ 1.812112] [01ba4c5e] libusb: debug [darwin_async_io_callback] an async io operation has completed
[ 1.812121] [01ba4c60] libusb: debug [usbi_wait_for_events] poll() returned 1
[ 1.812126] [01ba4c60] libusb: debug [handle_event_trigger] event triggered
[ 1.812129] [01ba4c60] libusb: debug [darwin_handle_transfer_completion] handling transfer completion type bulk with kernel status -536870163
[ 1.812132] [01ba4c60] libusb: warning [darwin_transfer_status] transfer error: device not responding (value = 0xe00002ed)
[ 1.812134] [01ba4c60] libusb: debug [usbi_handle_transfer_completion] transfer 0x156a04790 has callback 0x104429900
[ 1.812137] [01ba4c60] libusb: debug [sync_transfer_cb] actual_length=0
[ 1.812138] [01ba4c60] libusb: debug [darwin_handle_transfer_completion] handling transfer completion type bulk with kernel status -536870163
[ 1.812140] [01ba4c60] libusb: warning [darwin_transfer_status] transfer error: device not responding (value = 0xe00002ed)
[ 1.812141] [01ba4c60] libusb: debug [usbi_handle_transfer_completion] transfer 0x156b047f0 has callback 0x104429900
[ 1.812143] [01ba4c60] libusb: debug [sync_transfer_cb] actual_length=0
[ 1.812156] [01ba4c60] libusb: debug [libusb_get_next_timeout] no URBs, no timeout!
[ 1.812163] [01ba4cec] libusb: debug [libusb_free_transfer] transfer 0x156a04790
[ 1.812161] [01ba4ceb] libusb: debug [libusb_free_transfer] transfer 0x156b047f0
[ 1.812166] [01ba4c60] libusb: debug [libusb_handle_events_timeout_completed] doing our own event handling
[ 1.812183] [01ba4c60] libusb: debug [usbi_wait_for_events] poll() 1 fds with timeout in 60000ms
03-16 22:17:21.114 44660 28986604 D adb     : usb_libusb_device.cpp:106 LibUsbDevice::Write failed at header LIBUSB_ERROR_IO
03-16 22:17:21.114 44660 28986603 D adb     : usb_libusb_device.cpp:139 LibUsbDevice::READ failed at header LIBUSB_ERROR_IO
03-16 22:17:21.114 44660 28986604 I adb     : transport.cpp:1165 XXXXXXXXXX: connection terminated: write thread stopped
03-16 22:17:21.114 44660 28986603 I adb     : usb_libusb.cpp:94 XXXXXXXXXX: read failed: Undefined error: 0
03-16 22:17:21.114 44660 28986407 D adb     : fdevent_poll.cpp:194 (fdevent 0: fd 4 R) got events 1
03-16 22:17:21.114 44660 28986407 D adb     : adb.cpp:204 XXXXXXXXXX: already offline
03-16 22:17:21.114 44660 28986407 D adb     : transport.cpp:842 destroying transport XXXXXXXXXX
03-16 22:17:21.114 44660 28986407 I adb     : usb_libusb.cpp:174 LibUsbConnection(XXXXXXXXXX): stopping
[ 1.812262] [01ba4c27] libusb: debug [libusb_release_interface] interface 4
[ 1.861379] [01ba4c27] libusb: debug [libusb_close]  
[ 1.861461] [01ba4c5e] libusb: debug [darwin_devices_detached] notifying context 0x156904080 of device disconnect

Questions

Does it make sense to remove code found in the following lines https://cs.android.com/android/platform/superproject/main/+/main:packages/modules/adb/client/usb_libusb_device.cpp;l=470-478 as recommended in the libusb mailing list post https://sourceforge.net/p/libusb/mailman/libusb-devel/thread/1cc26359-d241-1061-4906-231ec0e28bab%40gmail.com/#msg38634913 ?
If we are missing something and the answer to question #1 is no, is it possible to make a code change to only call libusb_clear_halt() if ADB_OSX_USB_CLEAR_ENDPOINTS is set?

Please let me know if you have any additional questions.

Thank you.

Comments

ya...@gmail.com <ya...@gmail.com> #2Mar 19, 2025 05:45PM

Hello,

Thank you very much for letting us know. I understand that you have Python and Cloud SDK installed within directories in Windows OS where the full path contains spaces. Then you noticed that Cloud SDK wouldn't find properly the Python being installed and the gcloud commands wouldn't function properly.

I have reproduced the issue and indeed the Python installation was not properly detected while I can confirm that it is installed and working as expected. I have contacted the Cloud SDK engineering team and informed them about this issue. I don't have an ETA on the resolution of this issue, however, please keep following this thread ans any further updates will be posted directly here.

sa...@google.com <sa...@google.com> #3Mar 19, 2025 06:42PM

Comment has been deleted.

Message last modified on Mar 19, 2025 06:43PM

sa...@google.com <sa...@google.com> #4Mar 19, 2025 06:44PM

I have the same problem.

https://issuetracker.google.com/issues/146458535

== gcloud.cmd L.104
!CLOUDSDK_PYTHON! -c "import sys; print(sys.version)" >nul 2>&1
==

This line fails because the command part of the line is not quoted.
I think that Probably program name have to be quoted.

==
"!CLOUDSDK_PYTHON!" -c "import sys; print(sys.version)" >nul 2>&1
==

ya...@gmail.com <ya...@gmail.com> #5Mar 19, 2025 07:35PM

Hi, sorry for the inconvenience,
Can I have the output for `where python` and `where python3` from the system?

sa...@google.com <sa...@google.com> #6Mar 19, 2025 07:38PM

I'm having the same issue for Windows 10. I previously had cloud SDK installed and working with Python3. After the last SDK and windows updates though, it no longer finds the path. When I started SDK and ran any "gcloud" or "gsutil" command, I got the "python not on path" message. I've tried the below:

1) Creating a CLOUDSDK_PYTHON environment variable.
2) Changing my Path variable to various locations and also adding a PYTHONPATH variable.
3) Changing the SDK install and bat files.

Finally I just uninstalled everything and now I can't re-install SDK as it's giving me the same python not on path message. Screenshot attached. My python paths are at the top of my Path environment variable (screenshot attached). I'm out of ideas. The documentation is very confusing since 3/4 of it says that SDK ONLY works with python 2.7, and then the other 1/4 just doesn't work for me. The only thing I can think of is that technically I don't have a python.exe file in my python locations. Windows uses python launcher in which case the exe file is "C:\Windows\py.exe"

Any help is appreciated.

ya...@gmail.com <ya...@gmail.com> #7Mar 19, 2025 07:48PM

You can ignore my post. I fixed the problem by doing the following:

1) Uninstalled python37 and windows python launcher.
2) Re-installed python37 and re-added to the environment Path variable (This re-instated my missing python.exe file also; the py.exe file is also in it's Windows location for python launcher)
3) Deleted all previous SDK folders/files. (There was one still hanging out there from my previous copy)
4) Re-downloaded SDK and UNCHECKED the python bundle checkbox. It gave me a warning message that python was not installed, but after it completed, everything works as expected.

sa...@google.com <sa...@google.com> #8Mar 19, 2025 07:50PM

Comment has been deleted.

Message last modified on Mar 19, 2025 07:51PM

sa...@google.com <sa...@google.com> #9Mar 19, 2025 07:51PM

We have a solution for this now and are working on testing it and will post it here soon.
While we do that, blocked users can still use 273.0.0 (

https://dl.google.com/dl/cloudsdk/channels/rapid/downloads/google-cloud-sdk-274.0.0-windows-x86.zip) (32 bit) or (

https://dl.google.com/dl/cloudsdk/channels/rapid/downloads/google-cloud-sdk-273.0.0-windows-x86_64-bundled-python.zip) (64 bit) and use instructions from

https://cloud.google.com/sdk/docs/downloads-versioned-archives to get to a working state.

Apologies for the inconvenience, we will have the workaround and patch out soon.

ya...@gmail.com <ya...@gmail.com> #10Mar 21, 2025 09:16PM

We have a patch for two files that are causing these problems. These apply in two cases (both on Windows):
1. A new install fails, or
2. You are unable to run gcloud after performing a components update.

For case # 1, please download the attached file install.bat, and copy it to the location where you have attempted to install gcloud, e.g. C:\Program Files (x86)\Google\Cloud SDK\google-cloud-sdk. Then run it, e.g.
> cd C:\Program Files (x86)\Google\Cloud SDK\google-cloud-sdk
> .\install.bat

For both cases #1 and #2, download the attached file gcloud.cmd, and copy it to the bin directory under your gcloud installation, e.g.
C:\Program Files (x86)\Google\Cloud SDK\google-cloud-sdk\bin. When prompted to replace the previous copy, type Yes. This should allow you to run gcloud without being prompted to set CLOUDSDK_PYTHON.

ya...@gmail.com <ya...@gmail.com> #11Mar 21, 2025 09:44PM

This work around does not appear to work. I have tried it a number of times now, I am unable to run gcloud init after the install. I deleted everything and tried it again, this time even after copying the two patch files over, the installation doesn't even begin.

sa...@google.com <sa...@google.com> #12Mar 24, 2025 10:25PM

To de...@gmail.com, try the workaround I used as described in

https://issuetracker.google.com/issues/146652183 (i.e. install without the bundled python version)

ya...@gmail.com <ya...@gmail.com> #13Mar 25, 2025 03:24PM

wasted 2hrs for installing sdk... Claps...
and finally couldnt install sdk... Great work from u...

sa...@google.com <sa...@google.com> #14Mar 25, 2025 05:45PM

what should i do now... do u have any work around again

sa...@google.com <sa...@google.com> #15Mar 25, 2025 05:48PM

I changed path of installation of GCloudSDK to C:/GCloudSDK and it installed successfully.

ya...@gmail.com <ya...@gmail.com> #16Mar 25, 2025 09:02PM

I have tried what #15 suggested but to C:/GoogleCloudSDK, it works now.

Also, tried reopening project folders in Windows Subsystem for Linux (WSL) via Visual Studio Code-Remote WSL and using gcloud from within the WSL Ubuntu 18.04 distro as an alternative solution. That works too once configured.