Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OS Error 10014 (Bad address) when using "localhost" in UDP source address on Win7 #34202

Closed
joep27182 opened this issue Jun 10, 2016 · 2 comments

Comments

@joep27182
Copy link

joep27182 commented Jun 10, 2016

Consider this code:

use std::net::UdpSocket;

fn main() {
    let local_addr = "localhost:8900";
    let target_addr = "example.com:8900";

    let socket = UdpSocket::bind(local_addr).unwrap();
    let buf : [u8; 9] = [176,18,0,9,161,0,0,1,1];
    socket.send_to(&buf[..],target_addr).unwrap();
}

which fails like this:

thread '<main>' panicked at 'calledResult::unwrap()on anErrvalue: Error { repr: Os { code: 10014, message: "Bei dem Versuch das Zeigerargument eines Aufrufs zu\r\nverwenden, wurde eine ung\u{fc}ltige Zeigeradresse gefunden." } }', ../src/libcore\result.rs:746

The error occurs on the last line by the way.

If you write let local_addr="127.0.0.1:8900";, it works just fine (no panic).

If i remember correctly, this worked on Linux, so it should be an os specific issue. Of course you can just use an ip for the source address, but this kind of error shouldn't occur nevertheless right?

Meta

OS: Windows 7 Professional 64bit

rustc --version --verbose:
rustc 1.9.0 (e4e8b66 2016-05-18)
binary: rustc
commit-hash: e4e8b66
commit-date: 2016-05-18
host: x86_64-pc-windows-msvc
release: 1.9.0

Backtrace:

stack backtrace:
   0:        0x13f82138b - std::rt::lang_start::h5b0863080165c75e
   1:        0x13f82078b - std::rt::lang_start::h5b0863080165c75e
   2:        0x13f81449f - std::sys_common::unwind::begin_unwind_inner::h39d40f52add53ef7
   3:        0x13f814f8d - std::sys_common::unwind::begin_unwind_fmt::h64c0ff793199cc1b
   4:        0x13f81c4ab - rust_begin_unwind
   5:        0x13f824365 - core::panicking::panic_fmt::h73bf9d7e8e891a73
   6:        0x13f8115e3 - unwrap_failed<std::io::error::Error>
                        at [redacted]\src\libcore\macros.rs:29
   7:        0x13f812c34 - unwrap
                        at [redacted]\src\libcore\result.rs:687
   8:        0x13f811197 - main
                        at [redacted]\src\bin\test_udp_problem.rs:12
   9:        0x13f820158 - std::rt::lang_start::h5b0863080165c75e
  10:        0x13f81c418 - std::sys_common::thread_local::StaticKey::lazy_init::h0dbf04c687960888
  11:        0x13f81ff07 - std::rt::lang_start::h5b0863080165c75e
  12:        0x13f813179 - main
  13:        0x13f827c7a - __tmainCRTStartup
                        at f:\dd\vctools\crt\crtw32\dllstuff\crtexe.c:626
  14:         0x76cb59bc - BaseThreadInitThunk
@kennytm
Copy link
Member

kennytm commented Jun 10, 2016

Repo on Windows 10. Seems to crash on OS X as well.

The localhost is resolved to the IPv6 address [::1] and then the IPv4 address 127.0.0.1, and UdpSocket will only bind to the first address if successful. So the UDP socket is bound to an IPv6 address, and can only send data to IPv6 hosts.

Meanwhile, example.com is first resolved to the IPv4 address 93.184.216.34 and then the IPv6 one [2606:2800:220:1:248:1893:25c8:1946] (if the OS supports that). The implementation of send_to just send the data to the first address, regardless of if the result is Ok or Err.

The 10014 is due to sending data from IPv6 socket to IPv4 host.

So there are two problems shown from this issue:

  1. maybe send_to should use each_addr, or at least filter the address family?
  2. need to have some way to prioritize IPv4 address for localhost when using ToSocketAddrs. (IPv6 support is not good on internet, even if send_to picked [2606:...] it could still fail with 10049)

@alexcrichton
Copy link
Member

@kennytm's diagnosis sounds like it'd do it. We can probably figure out the local address type by calling local_addr and inspecting it, and then we should probably just filter the addresses returned to only those of the same kind.

achanda added a commit to achanda/rust that referenced this issue Nov 9, 2016
eddyb added a commit to eddyb/rust that referenced this issue Nov 9, 2016
Clarify that send_to might panic in certain cases

Closes rust-lang#34202

r? @alexcrichton
dgtony added a commit to dgtony/jctl2gray that referenced this issue Jun 18, 2018
wcampbell0x2a added a commit to wcampbell0x2a/rust that referenced this issue May 2, 2021
GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this issue May 3, 2021
GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this issue May 3, 2021
bors added a commit to rust-lang-ci/rust that referenced this issue May 3, 2021
…laumeGomez

Rollup of 6 pull requests

Successful merges:

 - rust-lang#84835 (Add link to Issue rust-lang#34202 in udp docs)
 - rust-lang#84852 (Change librustdoc write!(.. \n) to writeln!(..); fix comment grammar)
 - rust-lang#84854 (use double quotes and full path for E0761)
 - rust-lang#84856 (Correct stability of ErrorKind::OutOfMemory)
 - rust-lang#84858 (Fix stability attributes of byte-to-string specialization)
 - rust-lang#84860 (Link to MCP from target tier policy)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants