rust-ctor firing before rust std ctor?

[brandonros]

C:\tmp>rustup update
info: syncing channel updates for 'stable-i686-pc-windows-gnu'
info: syncing channel updates for 'stable-i686-pc-windows-msvc'
info: syncing channel updates for 'stable-x86_64-pc-windows-msvc'
info: syncing channel updates for 'nightly-i686-pc-windows-msvc'
info: checking for self-updates

     stable-i686-pc-windows-gnu unchanged - rustc 1.61.0 (fe5b13d68 2022-05-18)
    stable-i686-pc-windows-msvc unchanged - rustc 1.61.0 (fe5b13d68 2022-05-18)
  stable-x86_64-pc-windows-msvc unchanged - rustc 1.61.0 (fe5b13d68 2022-05-18)
   nightly-i686-pc-windows-msvc unchanged - rustc 1.63.0-nightly (fee3a459d 2022-06-05)

info: cleaning up downloads & tmp directories

cargo +nightly-i686-pc-windows-msvc build
Loading DLL: C:\dpdu-http\dpdu-http-vpi.dll
2022-06-06T17:33:06.648502400-04:00 DEBUG vpi - ctor
thread '<unnamed>' panicked at '`NtWriteFile` not available', library\std\src\sys\windows\c.rs:1293:9
stack backtrace:
   0: 0x6947214a - core::fmt::write
                       at /rustc/fee3a459dd6aba8e34a5b99f0fbcb4218a1e2401/library\core\src\fmt\mod.rs:1196
   1: 0x69452bb1 - std::io::Write::write_fmt<std::sys::windows::stdio::Stderr>
                       at /rustc/fee3a459dd6aba8e34a5b99f0fbcb4218a1e2401/library\std\src\io\mod.rs:1654
   2: 0x6945bbec - std::sys_common::backtrace::_print
                       at /rustc/fee3a459dd6aba8e34a5b99f0fbcb4218a1e2401/library\std\src\sys_common\backtrace.rs:48
   3: 0x6945bbec - std::sys_common::backtrace::print
                       at /rustc/fee3a459dd6aba8e34a5b99f0fbcb4218a1e2401/library\std\src\sys_common\backtrace.rs:35
   4: 0x6945bbec - std::panicking::default_hook::closure$1
                       at /rustc/fee3a459dd6aba8e34a5b99f0fbcb4218a1e2401/library\std\src\panicking.rs:295
   5: 0x6945b7d8 - std::panicking::default_hook
                       at /rustc/fee3a459dd6aba8e34a5b99f0fbcb4218a1e2401/library\std\src\panicking.rs:314
   6: 0x6945c2d7 - std::panicking::rust_panic_with_hook
                       at /rustc/fee3a459dd6aba8e34a5b99f0fbcb4218a1e2401/library\std\src\panicking.rs:698
   7: 0x6945c186 - std::panicking::begin_panic_handler::closure$0
                       at /rustc/fee3a459dd6aba8e34a5b99f0fbcb4218a1e2401/library\std\src\panicking.rs:586
   8: 0x6945a27f - std::sys_common::backtrace::__rust_end_short_backtrace<std::panicking::begin_panic_handler::closure_env$0,never$>
                       at /rustc/fee3a459dd6aba8e34a5b99f0fbcb4218a1e2401/library\std\src\sys_common\backtrace.rs:138
   9: 0x6945be52 - std::panicking::begin_panic_handler
                       at /rustc/fee3a459dd6aba8e34a5b99f0fbcb4218a1e2401/library\std\src\panicking.rs:584
  10: 0x6947b73f - core::panicking::panic_fmt
                       at /rustc/fee3a459dd6aba8e34a5b99f0fbcb4218a1e2401/library\core\src\panicking.rs:142
  11: 0x6945e3be - std::sys::windows::handle::Handle::synchronous_write
                       at /rustc/fee3a459dd6aba8e34a5b99f0fbcb4218a1e2401/library\std\src\sys\windows\handle.rs:309
  12: 0x6945e131 - std::sys::windows::handle::Handle::write
                       at /rustc/fee3a459dd6aba8e34a5b99f0fbcb4218a1e2401/library\std\src\sys\windows\handle.rs:195
  13: 0x6923aadf - std::io::buffered::bufwriter::BufWriter<std::fs::File>::flush_buf<std::fs::File>
                       at /rustc/fee3a459dd6aba8e34a5b99f0fbcb4218a1e2401\library\std\src\io\buffered\bufwriter.rs:166
  14: 0x692570fd - log4rs::encode::writer::simple::impl$0::flush<std::io::buffered::bufwriter::BufWriter<std::fs::File> >
                       at C:\Users\Brandon\.cargo\registry\src\github.com-1285ae84e5963aae\log4rs-1.0.0\src\encode\writer\simple.rs:19
  15: 0x6925654b - alloc::vec::impl$20::into_iter<alloc::boxed::Box<dyn$<log4rs::filter::Filter>,alloc::alloc::Global>,alloc::alloc::Global>
                       at /rustc/fee3a459dd6aba8e34a5b99f0fbcb4218a1e2401\library\alloc\src\vec\mod.rs:2671
  16: 0x692514d7 - log4rs::ConfiguredLogger::log
                       at C:\Users\Brandon\.cargo\registry\src\github.com-1285ae84e5963aae\log4rs-1.0.0\src\lib.rs:284
  17: 0x694438ed - log::RecordBuilder::build
                       at C:\Users\Brandon\.cargo\registry\src\github.com-1285ae84e5963aae\log-0.4.17\src\lib.rs:1141
  18:   0x19ee28 - <unknown>
  19: 0x68c128c5 - vpi::init___rust_ctor___ctor::init___rust_ctor___ctor
                       at C:\Users\Brandon\Desktop\dpdu-http\vpi\vpi.rs:847
  20: 0x7707ac47 - initterm
  21: 0x694797d0 - dllmain_crt_process_attach
                       at D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\dll_dllmain.cpp:64
  22: 0x6947972f - dllmain_crt_dispatch
                       at D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\dll_dllmain.cpp:219
  23: 0x69479957 - dllmain_dispatch
                       at D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\dll_dllmain.cpp:276
  24: 0x69479a50 - _DllMainCRTStartup
                       at D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\dll_dllmain.cpp:334
  25: 0x777f2976 - RtlIpv6AddressToStringA
  26: 0x777cdd22 - RtlActivateActivationContextUnsafeFast
  27: 0x777d1823 - RtlEqualUnicodeString
  28: 0x777d1991 - RtlEqualUnicodeString
  29: 0x777d2235 - RtlIsCriticalSectionLockedByThread
  30: 0x777ce252 - LdrLoadDll
  31: 0x777cde96 - LdrLoadDll
  32: 0x77381526 - LoadLibraryExW
  33: 0x77382042 - LoadLibraryA
  34:   0x4bf79a - <unknown>
  35:   0x41c52c - <unknown>
  36:   0x516193 - <unknown>
  37:   0x515f5d - <unknown>
  38: 0x75dcfa29 - BaseThreadInitThunk
  39: 0x777e7a7e - RtlGetAppContainerNamedObjectPath
  40: 0x777e7a4e - RtlGetAppContainerNamedObjectPath

[brandonros]

probably not this library, unless for some reason ctor is like... not waiting for C/C++ runtime of MSVC? i don't know... just a guess.

[brandonros]

fyi estk/log4rs#263 (comment)

[ChrisDenton]

A temporary workaround you could try is something like this:

#[used]
#[link_section = ".CRT$XCV"]
static INIT_TABLE_ENTRY: unsafe extern "C" fn() = init;

// initialization function.
unsafe extern "C" fn init() {
    /* ctor code goes here */
}

This uses the .CRT$XCV section whereas the standard library uses the .CRT$XCU section. This works because the sections are ordered using the letters after the $.

[mmastrac]

Thanks for the detailed report. Should we modify the library to use .CRT$XCV everywhere? Will that have unintended side-effects?

[ChrisDenton]

I think this should be fixed in the standard library. That said, there shouldn't currently be any particular harm to using .CRT$XCV everywhere although it is somewhat off-label: https://docs.microsoft.com/en-us/cpp/c-runtime-library/crt-initialization?view=msvc-160

The names .CRT$XCT and .CRT$XCV aren't used by either the compiler or the CRT library right now, but there's no guarantee that they'll remain unused in the future.

[ChrisDenton]

Ok, I did a quick write up of the underlying issue on the Rust repository and also made a PR to address it.

[CGMossa]

Oh this issue is fixed? Should this then be closed?