steffengy / tiberius

TDS 7.4 (mssql / Microsoft SQL Server) async driver for rust. Fork at: https://github.com/prisma/tiberius
Apache License 2.0
150 stars 2 forks source link

Tiberius unable to connect to sql when compiled in release #87

Closed danylaporte closed 5 years ago

danylaporte commented 5 years ago

This is a weird behavior. When compiled in debug mode, the code is working but when compiled in release mode, it failed with the following panic:

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Io(Os { code: 10047, kind: Other, message: "An address incompatible with the requested protocol was used." })', src\libcore\result.rs:1009:5
stack backtrace:
   0: std::sys::windows::backtrace::set_frames
             at /rustc/14997d56a550f4aa99fe737593cd2758227afc56\/src\libstd\sys\windows\backtrace\mod.rs:104
   1: std::sys::windows::backtrace::set_frames
             at /rustc/14997d56a550f4aa99fe737593cd2758227afc56\/src\libstd\sys\windows\backtrace\mod.rs:104
   2: std::sys::windows::backtrace::set_frames
             at /rustc/14997d56a550f4aa99fe737593cd2758227afc56\/src\libstd\sys\windows\backtrace\mod.rs:104
   3: std::sys_common::backtrace::print
             at /rustc/14997d56a550f4aa99fe737593cd2758227afc56\/src\libstd\sys_common\backtrace.rs:59
   4: std::sys_common::backtrace::print
             at /rustc/14997d56a550f4aa99fe737593cd2758227afc56\/src\libstd\sys_common\backtrace.rs:59
   5: std::panicking::default_hook
             at /rustc/14997d56a550f4aa99fe737593cd2758227afc56\/src\libstd\panicking.rs:227
   6: std::panicking::rust_panic_with_hook
             at /rustc/14997d56a550f4aa99fe737593cd2758227afc56\/src\libstd\panicking.rs:491
   7: std::panicking::continue_panic_fmt
             at /rustc/14997d56a550f4aa99fe737593cd2758227afc56\/src\libstd\panicking.rs:398
   8: std::panicking::rust_begin_panic
             at /rustc/14997d56a550f4aa99fe737593cd2758227afc56\/src\libstd\panicking.rs:325
   9: core::panicking::panic_fmt
             at /rustc/14997d56a550f4aa99fe737593cd2758227afc56\/src\libcore\panicking.rs:95
  10: core::result::unwrap_failed
  11: <alloc::collections::vec_deque::VecDeque<T> as core::ops::drop::Drop>::drop
  12: <T as core::any::Any>::get_type_id
  13: std::rt::lang_start_internal::{{closure}}
             at /rustc/14997d56a550f4aa99fe737593cd2758227afc56\/src\libstd\rt.rs:59
  14: std::rt::lang_start_internal::{{closure}}
             at /rustc/14997d56a550f4aa99fe737593cd2758227afc56\/src\libstd\rt.rs:59
  15: panic_unwind::__rust_maybe_catch_panic
             at /rustc/14997d56a550f4aa99fe737593cd2758227afc56\/src\libpanic_unwind\lib.rs:102
  16: std::panicking::try
             at /rustc/14997d56a550f4aa99fe737593cd2758227afc56\/src\libstd\panicking.rs:289
  17: std::panicking::try
             at /rustc/14997d56a550f4aa99fe737593cd2758227afc56\/src\libstd\panicking.rs:289
  18: std::panicking::try
             at /rustc/14997d56a550f4aa99fe737593cd2758227afc56\/src\libstd\panicking.rs:289
  19: main
  20: invoke_main
             at d:\agent\_work\2\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:78
  21: invoke_main
             at d:\agent\_work\2\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:78
  22: BaseThreadInitThunk
  23: RtlUserThreadStart
use tiberius::SqlConnection;

fn main() {
    tokio::executor::current_thread::block_on_all(
        SqlConnection::connect("server=tcp:127.0.0.1\\Sql2017;database=Database;integratedsecurity=sspi;trustservercertificate=true")
    ).unwrap();

    println!("Done.");
}

It used to works in release mode but I cannot say when it started not working. Cargo.toml does not have any patch on the dependency. I am using the very latest nightly.

steffengy commented 5 years ago

That looks interesting, can you also reproduce with stable/beta?

danylaporte commented 5 years ago

It works using the stable toolchain. I will try the beta.

danylaporte commented 5 years ago

It does not work in the beta toolchain. Same as in nightly.

steffengy commented 5 years ago

I can reproduce the issue locally.

steffengy commented 5 years ago

Cannot produce a reduced testset so far. The error is triggered (but likely not caused by) in miow::CompletionPort::get_many. If I remove enough code from tiberius it isn't triggered anymore, leading me to believe we're dealing with a lower level issue here (possibly optimization).

A short workaround should be not using instance-lookups (specifying a TCP port).

danylaporte commented 5 years ago

Ok, thanks. I will try that. If I use a UDP socket to invoke the SQL Browser service just before Tiberius, I get it to work but the same call inside Tiberius is failing. I will bypass the SQL Browser service for now. Thanks again.

danylaporte commented 5 years ago

If I make the function parse_connection_str in lib.rs public, the issue goes away.

steffengy commented 5 years ago

Yeah sure anything that effects optimization will cause this to go away, upstream LLVM bug for the underlying issue has been filed.

danylaporte commented 5 years ago

Thanks for all your hard work on this bug! I saw the "regression in rust-nightly" issue.

steffengy commented 5 years ago

@danylaporte Should work with the next nightly now.

danylaporte commented 5 years ago

@steffengy It works now in nightly. Thank you very much for all your hard work on this issue.