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

Panic on socket connect on MacOS Mojave #9

Open
n8henrie opened this issue Jan 2, 2019 · 4 comments
Open

Panic on socket connect on MacOS Mojave #9

n8henrie opened this issue Jan 2, 2019 · 4 comments
Labels
bug Something isn't working os:macos

Comments

@n8henrie
Copy link

n8henrie commented Jan 2, 2019

MacOS 10.14.2
rustc 1.31.1 (b6c32da9b 2018-12-18)

Panics at socket.connect("239.255.255.250:1900").unwrap(); in src/dlna/discovery.rs.

$ RUST_BACKTRACE=1 target/debug/rustymedia -l stuff=~/Movies | pbcopy
Listening on http://[fe80::c2c:d1e:7cd:7918]:4950/
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 22, kind: InvalidInput, message: "Invalid argument" }', libcore/result.rs:1009:5
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::print
             at libstd/sys_common/backtrace.rs:71
             at libstd/sys_common/backtrace.rs:59
   2: std::panicking::default_hook::{{closure}}
             at libstd/panicking.rs:211
   3: std::panicking::default_hook
             at libstd/panicking.rs:227
   4: <std::panicking::begin_panic::PanicPayload<A> as core::panic::BoxMeUp>::get
             at libstd/panicking.rs:476
   5: std::panicking::continue_panic_fmt
             at libstd/panicking.rs:390
   6: std::panicking::try::do_call
             at libstd/panicking.rs:325
   7: core::ptr::drop_in_place
             at libcore/panicking.rs:77
   8: core::alloc::Layout::repeat
             at libcore/macros.rs:26
   9: futures::task_impl::NotifyHandle::new
             at libcore/result.rs:808
  10: <hyper::proto::request::Request>::body
             at src/dlna/discovery.rs:13
  11: rustymedia::result_main
             at src/bin/rustymedia.rs:94
  12: rustymedia::main
             at src/bin/rustymedia.rs:103
  13: std::rt::lang_start::{{closure}}
             at libstd/rt.rs:74
  14: std::panicking::try::do_call
             at libstd/rt.rs:59
             at libstd/panicking.rs:310
  15: panic_unwind::imp::find_eh_action::{{closure}}
             at libpanic_unwind/lib.rs:102
  16: std::alloc::default_alloc_error_hook
             at libstd/panicking.rs:289
             at libstd/panic.rs:392
             at libstd/rt.rs:58
  17: std::rt::lang_start
             at libstd/rt.rs:74
  18: rustymedia::main
@kevincox kevincox added bug Something isn't working os:macos labels Jan 3, 2019
@kevincox
Copy link
Owner

kevincox commented Jan 3, 2019

To be honest don't have any clue what the problem is here. It guess we would have to find out how to do this broadcast on macos.

@n8henrie
Copy link
Author

n8henrie commented Jan 3, 2019

Just some notes while I look into it (mostly for my reference, you likely know all this).

I have a Python app that makes a similar UPnP broadcast. It binds '':1900, where '' is INADDR_ANY for IPV4 addresses.

:: is the IPv6 unspecified address, as defined here.

Could it be because :: is an IPv6 address, and 239.255.255.250 is an IPv4 broadcast address? I don't know why this would run on Linux but not MacOS, but it builds and runs (on both MacOS and Linux) if I change the line to: let socket = std::net::UdpSocket::bind("0.0.0.0:0").unwrap();.

EDIT:
Not sure if this is relevant, but if I debug print the socket before and after connect in Arch Linux:

Listening on http://192.168.0.65:4950/
UdpSocket { addr: V6([::]:45885), fd: 9 }
UdpSocket { addr: V6([::ffff:192.168.0.65]:45885), fd: 9 }

Note the IPv4 address at the last line.

@n8henrie
Copy link
Author

I still look at this issue from time to time but haven't made any progress.

My thread at the rust forum hasn't gotten much attention either: https://users.rust-lang.org/t/ipv6-upnp-multicast-for-rust-dlna-server-macos/24425/2

@kevincox
Copy link
Owner

That's too bad. Unfortunately I don't have access to a Mac for any sort of debugging so I won't be able to help out. If you do find a possible fix I can verify it on Linux but that is about it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working os:macos
Projects
None yet
Development

No branches or pull requests

2 participants