In an earlier code review it was pointed out that there was something
very weird about fail_errno. It didn't seem to make sense that we'd
often try to continue after reporting failure. This patch cleans up
all that and assumes that if we've reported failure to the client,
we should stop what we're doing.
Bug: http://b/23437039
Change-Id: I39c38650ed9f9d5e30adbf68a7545c9e4a6ab812
We can double the speed of "adb sync" (on N9) if we increase SYNC_DATA_MAX
from 64KiB to 256KiB. This change doesn't do that, because I still haven't
managed to plumb through the information about whether we're a new adb/adbd
to file_sync_client.cpp and file_sync_service.cpp. But this is already a big
change with a lot of cleanup, so let's do the cleanup and worry about the
intended change another day...
This change does improve performance somewhat by halving the number of
lstat(2) calls made on the client side, and ensuring that most packets are
sent with a single write. This has the pleasing result of making the null
sync on an AOSP N9 go from just over 300ms to around 100ms, which means it
now seems instantaneous (https://en.wikipedia.org/wiki/Mental_chronometry).
Change-Id: If9f6d4c1f93ec752b95f71211bbbb1c513045166
adb on Windows uses \r\n line-endings, so take that into account when
parsing output for the exit code.
Change-Id: I6a3d7c5ca455b0f0f7dae174866857e0aeee9926
Signed-off-by: Spencer Low <CompareAndSwap@gmail.com>
This allows us to test for features explicitly rather than relying on
the protocol version number, allowing us to fall back gracefully if a
feature is not supported.
This will be needed for the upcoming shell upgrades for stdout/stderr
separation and exit code reporting.
Change-Id: Ibb1d8ad2611f7209901ee76d51346b453e9c5873
This CL clears both the host and device endpoints right at the
beginning when the bulk endpoints are identified. This is in general
a "good idea", but more specifically for us, it fixes the issue
that sometimes when adb quits, it clears the endpoint on the host,
but not on the device which resulted in a subsequent invocation of
adb was seeing a stall.
Bug: https://code.google.com/p/android/issues/detail?id=182151
Change-Id: I331fa6805c40d1f50c153c010ceecd2f6a4045eb
- handle_host_request
- When the host:kill command comes in, shutdown the socket before
calling exit(). If we don't do this, the client will output error info
even though everything is working ok.
- adb_connect()
- If we can't parse the version string, explain this in error output
and don't goto error which would try to close an fd we already closed.
- If host:kill doesn't work, output error info. Don't try to close
already closed fd.
- adb_main()
- If writing the ACK somehow has an error, output error info (I doubt
this will ever get hit).
- adb_commandline()
- Fix typo about max port number.
- Make 'adb kill-server' and 'adb start-server' output any detailed
error info.
Change-Id: Id1a309cc1bf516f7f49bd332b34d30f148b406da
Signed-off-by: Spencer Low <CompareAndSwap@gmail.com>
adb can hang at shutdown due to a deadlock relating to WSACleanup().
This works around the issue by not calling WSACleanup() which shouldn't
be done anyway since threads aren't done using Winsock at shutdown.
A quick way to reproduce the original problem is to run many instances
of adb, many of which will call exit() soon:
for /l %i in (1,1,20) do @start adb nodaemon server
You may have to boost the 20 to 200, or set ADB_TRACE=1 or use Windows
10 instead of Windows 7, to affect the timing, but eventually there
should be hung adb processes with that repro.
A more complete fix to prevent problems like this from occuring in the
future, would be to additionally do the following:
- Investigate all static destructors that are called when exit() is
called.
- If they don't do anything important, switch all calls to exit() to
instead call _exit() and then ban exit() from being called.
Change-Id: Id1be3bf0053809a45f2eca4461e4c35b5ef9388d
Signed-off-by: Spencer Low <CompareAndSwap@gmail.com>
Change `adb shell` so that interactive sessions use a PTY but
non-interactive do not. This matches `ssh` functionality better
and also enables future work to split stdout/stderr for
non-interactive sessions.
A test to verify this behavior is added to test_device.py with
supporting modifications in device.py.
Bug: http://b/21215503
Change-Id: Ib4ba40df85f82ddef4e0dd557952271c859d1c7b
Make these fatal errors:
- Win32 GetTempPathW() failures.
- Errors opening /dev/null (and don't use LOG(FATAL) for this error
since that will do a crash-dump on Windows which isn't appropriate for a
transient runtime error).
- Errors with dup2.
- Errors opening adb.log.
Change-Id: Ided76a5436d8c6f059d8f6799c49ba04c87181ae
Signed-off-by: Spencer Low <CompareAndSwap@gmail.com>
- handle_forward_request
- Because we have detailed info about which syscall failed (at least
on Win32), use a more generic prefix of "cannot bind listener" followed
by the detailed info.
- install_listener
- Return string errors for a few errors even though I don't think any
callers actually output the string for those errors.
- Remove the printf since the callers print the message themselves.
- adb_main
- LOG(FATAL) calls abort() which on Windows calls the Windows Error
Reporting service which pops up a dialog asking if you want a
crashdump to be uploaded to Microsoft. So really, abort() is
designed for app bugs. Windows isn't the only one doing this, Chromium
also makes LOG(FATAL) crashdump-ready. Since an error here is not
necessarily an app-bug, use a 'normal' error output API like fatal()
which prints an error and just uses exit().
- sysdeps_win32.cpp
- When Winsock APIs fail, make the string clarify which API failed.
Use terse unix-style descriptions (like what you'd get from
cp/mv/dd/etc.).
- Don't trace WSAEWOULDBLOCK from recv() which is a normal occurrence.
- Add a comment about WSAEWOULDBLOCK => EAGAIN.
Change-Id: I58e47f49fa2f6c1b4b92a36d0c4bfe369b456f2a
Signed-off-by: Spencer Low <CompareAndSwap@gmail.com>
This is a follow-up to https://android-review.googlesource.com/153623
which prevented android::base::InitLogging() from being called when
tracing was disabled.
It is ok to call InitLogging() on a device or host because calling it
does not imply that a logging file is used, which was the reason for
not calling it on a device.
So this change should preserve the device behavior of not using a
logging file when tracing is disabled, plus it will call InitLogging()
all the time in case logging APIs are called.
Change-Id: I3fd6ba2c567f67a2f111a85f174893fbf866ec57
Signed-off-by: Spencer Low <CompareAndSwap@gmail.com>
