diesel_cli commands give access violation error on Windows 10

[lazear]

Setup

Versions

• Rust: rustc 1.37 stable
• Diesel: 1.4.0
• Database: Postgres 11.5
• Operating System: Windows 10

Feature Flags

• diesel: --no-default-features --features postgres

Problem Description

Attempting to run diesel setup, diesel migration run, or other commands results in a silent exit. $LASTEXITCODE gives an answer of -1073741819, or 0xC0000005 in hex, which is Window's STATUS_ACCESS_VIOLATION code.

The diesel executable itself operates properly if no database connection needs to be made - it can generate a migration folder and output help information, etc.

Attempting to use a build script to perform migrations results in (exit code: 0xc0000005, STATUS_ACCESS_VIOLATION)

use diesel::prelude::*;
use diesel::pg::PgConnection;
use diesel_migrations;
use dotenv::dotenv;
use std::env;

pub fn establish_connection() -> PgConnection {
    dotenv().ok();
    let database_url = env::var("DATABASE_URL")
        .expect("DATABASE_URL must be set");
    PgConnection::establish(&database_url)
        .expect(&format!("Error connecting to {}", database_url))
}

fn main() {
    let connection = establish_connection();
    diesel_migrations::run_pending_migrations(&connection).unwrap();
}

No changes to the database have been made after running these commands.

HOWEVER, Using the diesel crate, code (from demo) can successfully connect to and manipulate the Postgres database, after manually setting up the database schema, since migrations are not working. This verifies that all of the DLLs are in place, and environment variables are properly set.

What are you trying to accomplish?

Trying to follow the https://diesel.rs/guides/getting-started/ guide

What is the expected output?

Expect that database should be altered.

What is the actual output?

No output. Silent exit with access code violation

Are you seeing any additional errors?

$LASTEXITCODE gives an answer of -1073741819, or 0xC0000005 in hex, which is Window's ACCESS VIOLATION code.

Steps to reproduce

1. $env:PQ_LIB_DIR = "C:\Program Files\PostgreSQL\11\lib"
2. $env:VCPKGRS_DYNAMIC=1
3. C:\Program Files\PostgreSQL\11\lib is added to path (along with vcpkg install)
4. cargo install diesel_cli --no-default-features --features postgres,sqlite
   diesel.exe --help
5. Properly set DATABASE_URL environment variable - same one is used for working code

Checklist

• I have already looked over the issue tracker for similar issues.
• This issue can be reproduced on Rust's stable channel. (Your issue will be
  closed if this is not the case)

[lazear]

Compiling diesel_cli myself gives the results in the following callstack on a diesel migration run command:

Exception thrown at 0x00007FFB28C11F70 (ucrtbase.dll) in diesel.exe: 0xC0000005: Access violation reading location 0x0000000000000001.

ucrtbase.dll!00007ffb28c11f70() (Unknown Source:0)
diesel.exe!std::ffi::c_str::CStr::from_ptr() Line 967 (c:\rustc\eae3437dfe991621e8afdc82734f4a172d7ddf9b\src\libstd\ffi\c_str.rs:967)
diesel.exe!diesel::pg::connection::raw::last_error_message(pq_sys::pg_conn * conn) Line 108 (c:\Users\Michael\.cargo\registry\src\github.com-1ecc6299db9ec823\diesel-1.4.2\src\pg\connection\raw.rs:108)
diesel.exe!diesel::pg::connection::raw::RawConnection::establish(str* database_url) Line 34 (c:\Users\Michael\.cargo\registry\src\github.com-1ecc6299db9ec823\diesel-1.4.2\src\pg\connection\raw.rs:34)
diesel.exe!diesel::pg::connection::{{impl}}::establish(str* database_url) Line 50 (c:\Users\Michael\.cargo\registry\src\github.com-1ecc6299db9ec823\diesel-1.4.2\src\pg\connection\mod.rs:50)
diesel.exe!diesel::database::InferConnection::establish(str* database_url) Line 88 (c:\Users\Michael\.cargo\registry\src\github.com-1ecc6299db9ec823\diesel_cli-1.4.0\src\database.rs:88)
diesel.exe!diesel::run_migration_command(clap::args::arg_matches::ArgMatches * matches) Line 82 (c:\Users\Michael\.cargo\registry\src\github.com-1ecc6299db9ec823\diesel_cli-1.4.0\src\main.rs:82)
diesel.exe!diesel::main() Line 65 (c:\Users\Michael\.cargo\registry\src\github.com-1ecc6299db9ec823\diesel_cli-1.4.0\src\main.rs:65)
diesel.exe!std::rt::lang_start::{{closure}}<()>(closure *) Line 64 (c:\rustc\eae3437dfe991621e8afdc82734f4a172d7ddf9b\src\libstd\rt.rs:64)
[Inline Frame] diesel.exe!std::rt::lang_start_internal::{{closure}}() (Unknown Source:0)
diesel.exe!std::panicking::try::do_call<closure,i32>() Line 296 (c:\rustc\eae3437dfe991621e8afdc82734f4a172d7ddf9b\src\libstd\panicking.rs:296)
diesel.exe!panic_unwind::__rust_maybe_catch_panic() Line 82 (c:\rustc\eae3437dfe991621e8afdc82734f4a172d7ddf9b\src\libpanic_unwind\lib.rs:82)
[Inline Frame] diesel.exe!std::panicking::try() Line 280 (c:\rustc\eae3437dfe991621e8afdc82734f4a172d7ddf9b\src\libstd\panicking.rs:280)
[Inline Frame] diesel.exe!std::panic::catch_unwind() Line 394 (c:\rustc\eae3437dfe991621e8afdc82734f4a172d7ddf9b\src\libstd\panic.rs:394)
diesel.exe!std::rt::lang_start_internal() Line 48 (c:\rustc\eae3437dfe991621e8afdc82734f4a172d7ddf9b\src\libstd\rt.rs:48)
diesel.exe!std::rt::lang_start<()>(void(*)() main, __int64 argc, unsigned char * * argv) Line 64 (c:\rustc\eae3437dfe991621e8afdc82734f4a172d7ddf9b\src\libstd\rt.rs:64)
diesel.exe!main�() (Unknown Source:0)
[Inline Frame] diesel.exe!invoke_main() Line 78 (d:\agent\_work\3\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:78)
diesel.exe!__scrt_common_main_seh() Line 288 (d:\agent\_work\3\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288)
kernel32.dll!00007ffb28fa7bd4() (Unknown Source:0)

[weiznich]

Ok that seems strange.

Properly set DATABASE_URL environment variable - same one is used for working code

The only possibility to reach that code state shown in the stack trace is by failing to establish a connection here, so something may be wrong with your DATABASE_URL.
It would be interesting to know which connection status is returned there. Any possibility that you run that code in a debugger and extract the value of connection_status before entering last_error_message?

That written: We should not segfault in such cases. I'm not sure if the right fix is to guard from null pointers in last_error_messages or if that never should happen and we should better handle that specific connection status separately.

[lazear]

I'm getting bogus and spurious values for let connection_status = unsafe { PQstatus(connection_ptr) }; such as 3188317072 or 1157156160. Half the time the debugger can't even step through this line, as it's reporting an exception in the PQ C library

libpq.dll!conninfo_array_parse(const char * const * keywords, const char * const * values, PQExpBufferData * errorMessage, char use_defaults, int expand_dbname) Line 4452 (d:\Documents\GitHub\vcpkg\buildtrees\libpq\src\stgresql-9-d40671c654\src\interfaces\libpq\fe-connect.c:4452)
libpq.dll!PQconnectStartParams(const char * const * keywords, const char * const * values, int expand_dbname) Line 581 (d:\Documents\GitHub\vcpkg\buildtrees\libpq\src\stgresql-9-d40671c654\src\interfaces\libpq\fe-connect.c:581)
libpq.dll!PQconnectdbParams(const char * const * keywords, const char * const * values, int expand_dbname) Line 465 (d:\Documents\GitHub\vcpkg\buildtrees\libpq\src\stgresql-9-d40671c654\src\interfaces\libpq\fe-connect.c:465)
diesel.exe!diesel::pg::connection::raw::RawConnection::establish(str* database_url) Line 26 (c:\Users\Michael\.cargo\registry\src\github.com-1ecc6299db9ec823\diesel-1.4.2\src\pg\connection\raw.rs:26)
diesel.exe!diesel::pg::connection::{{impl}}::establish(str* database_url) Line 50 (c:\Users\Michael\.cargo\registry\src\github.com-1ecc6299db9ec823\diesel-1.4.2\src\pg\connection\mod.rs:50)
diesel.exe!diesel::database::create_database_if_needed(str* database_url) Line 147 (c:\Users\Michael\.cargo\registry\src\github.com-1ecc6299db9ec823\diesel_cli-1.4.0\src\database.rs:147)
diesel.exe!diesel::database::setup_database(clap::args::arg_matches::ArgMatches * args, std::path::Path * migrations_dir) Line 131 (c:\Users\Michael\.cargo\registry\src\github.com-1ecc6299db9ec823\diesel_cli-1.4.0\src\database.rs:131)
diesel.exe!diesel::run_setup_command(clap::args::arg_matches::ArgMatches * matches) Line 203 (c:\Users\Michael\.cargo\registry\src\github.com-1ecc6299db9ec823\diesel_cli-1.4.0\src\main.rs:203)
diesel.exe!diesel::main() Line 66 (c:\Users\Michael\.cargo\registry\src\github.com-1ecc6299db9ec823\diesel_cli-1.4.0\src\main.rs:66)
diesel.exe!std::rt::lang_start::{{closure}}<()>(closure *) Line 64 (c:\rustc\eae3437dfe991621e8afdc82734f4a172d7ddf9b\src\libstd\rt.rs:64)
[Inline Frame] diesel.exe!std::rt::lang_start_internal::{{closure}}() (Unknown Source:0)
diesel.exe!std::panicking::try::do_call<closure,i32>() Line 296 (c:\rustc\eae3437dfe991621e8afdc82734f4a172d7ddf9b\src\libstd\panicking.rs:296)
diesel.exe!panic_unwind::__rust_maybe_catch_panic() Line 82 (c:\rustc\eae3437dfe991621e8afdc82734f4a172d7ddf9b\src\libpanic_unwind\lib.rs:82)
[Inline Frame] diesel.exe!std::panicking::try() Line 280 (c:\rustc\eae3437dfe991621e8afdc82734f4a172d7ddf9b\src\libstd\panicking.rs:280)
[Inline Frame] diesel.exe!std::panic::catch_unwind() Line 394 (c:\rustc\eae3437dfe991621e8afdc82734f4a172d7ddf9b\src\libstd\panic.rs:394)
diesel.exe!std::rt::lang_start_internal() Line 48 (c:\rustc\eae3437dfe991621e8afdc82734f4a172d7ddf9b\src\libstd\rt.rs:48)
diesel.exe!std::rt::lang_start<()>(void(*)() main, __int64 argc, unsigned char * * argv) Line 64 (c:\rustc\eae3437dfe991621e8afdc82734f4a172d7ddf9b\src\libstd\rt.rs:64)
diesel.exe!main�() (Unknown Source:0)
[Inline Frame] diesel.exe!invoke_main() Line 78 (d:\agent\_work\3\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:78)
diesel.exe!__scrt_common_main_seh() Line 288 (d:\agent\_work\3\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288)

There is something quite bizarre happening - If I execute diesel_cli via cargo run --no-default-features --features postgres database reset --database-url postgres://postgres:secret@localhost/testdb ... it works

However target\debug\diesel.exe database reset --database-url postgres://postgres:secret@localhost/testdb does not

[lazear]

EDIT: This seems to be solely a linking error, or something wrong with the vcpkg generated library. Linking against C:\Program Files\Postgres\11\lib\libpq.dll only (moving it's position in PATH, PQ_LIB_DIR), seems to be working

[weiznich]

Probably #813 is related here?

[weiznich]

According to the comment above that seemed to be a linker issue.