Skip to content
This repository has been archived by the owner on May 10, 2020. It is now read-only.

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

Closed
danylaporte opened this issue Dec 7, 2018 · 11 comments
Closed

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

danylaporte opened this issue Dec 7, 2018 · 11 comments

Comments

@danylaporte
Copy link
Contributor

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
Copy link
Owner

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

@danylaporte
Copy link
Contributor Author

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

@danylaporte
Copy link
Contributor Author

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

@steffengy
Copy link
Owner

I can reproduce the issue locally.

@steffengy
Copy link
Owner

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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

@steffengy
Copy link
Owner

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

@danylaporte
Copy link
Contributor Author

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

@steffengy
Copy link
Owner

@danylaporte
Should work with the next nightly now.

@danylaporte
Copy link
Contributor Author

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants