Diagnostic Server Fails on macOS 14.4

[abhillman]

Problem

$ cargo clippy --fix
error: failed to bind TCP listener to manage locking

Caused by:
  Can't assign requested address (os error 49)

Notes

Panic arises in the diagnostic server:

cargo/src/cargo/util/diagnostic_server.rs

Line 231 in 3a18c89

let listener = TcpListener::bind("127.0.0.1:0")

This may be a bug in macOS or rust itself as this simple program fails on my platform:

$ cat > example.rs && rustc example.rs && ./example
use std::net::TcpListener;

fn main() {
  let _ = TcpListener::bind("127.0.0.1:0").unwrap();
}
thread 'main' panicked at example.rs:4:44:
called `Result::unwrap()` on an `Err` value: Os { code: 49, kind: AddrNotAvailable, message: "Can't assign requested address" }
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

rust-lang/rust#123715 (comment)

Version

$ cargo version --verbose                          
cargo 1.78.0 (54d8815d0 2024-03-26)
release: 1.78.0
commit-hash: 54d8815d04fa3816edc207bbc4dd36bf18014dbc
commit-date: 2024-03-26
host: aarch64-apple-darwin
libgit2: 1.7.2 (sys:0.18.2 vendored)
libcurl: 8.4.0 (sys:0.4.72+curl-8.6.0 system ssl:(SecureTransport) LibreSSL/3.3.6)
ssl: OpenSSL 1.1.1w  11 Sep 2023
os: Mac OS 14.4.0 [64-bit]

[weihanglo]

Could you run ifconfig lo0 or something similar, and check if the loopback device is up and 127.0.0.1 is its address?

[abhillman]

Indeed, loopback is up, but is it assigned a LAN IP. I had noticed this as well; it is quite curious.

$ ifconfig lo0
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
	options=1203<RXCSUM,TXCSUM,TXSTATUS,SW_TIMESTAMP>
	inet6 ::1 prefixlen 128
	inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
	inet 192.168.1.88 netmask 0xffffffff
	nd6 options=201<PERFORMNUD,DAD>
$ ifconfig | rg '127' # no result
$ ifconfig | rg 'localhost' # no result

[abhillman]

This appears to resolve the issues with cargo run clippy --fix and the above rust code:

$ sudo ifconfig lo0 alias 127.0.0.1

That said, I don't believe that macOS ships with the 127.0.0.1 alias on lo0. I will see what I can do to run a test with a fresh install on a VM and/or CI. If indeed, macOS does not ship with 127.0.0.1 as a loopback alias, it seems to me that some kind of workaround for cargo may be appropriate. lmkwyt.

[abhillman]

Ok, a vm running a fresh install of macOS 14.3 indeed has 127.0.0.1 set up as an alias. I will see what happens with an upgrade to 14.4. This may just be a "my box" (perhaps sometimes other boxes?) problem.

[weihanglo]

Have a shot-in-the-dark. @abhillman could you help verify it?
#13907