Repository navigation
Encounter STATUS_STACK_BUFFER_OVERRUN when compiling diesel on windows 10 #72084
Description
When I compile Diesel, I encounter this error:
process didn't exit successfully: `rustc --crate-name diesel C:\Users\w9316\.cargo\git\checkouts\diesel-cabefa622aec6f57\701a2b5\diesel\src\lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts --crate-type lib --emit=dep-info,metadata,link -Cembed-bitcode=no -C debuginfo=2 --cfg "feature=\"128-column-tables\"" --cfg "feature=\"32-column-tables\"" --cfg "feature=\"64-column-tables\"" --cfg "feature=\"default\"" --cfg "feature=\"libsqlite3-sys\"" --cfg "feature=\"r2d2\"" --cfg "feature=\"sqlite\"" --cfg "feature=\"with-deprecated\"" -C metadata=b3c713a37a3f458d -C extra-filename=-b3c713a37a3f458d --out-dir D:\xxx\target\debug\deps -L dependency=D:\xxx\target\debug\deps --extern byteorder=D:\xxx\target\debug\deps\libbyteorder-9000b67aab64cc67.rmeta --extern crossbeam_utils=D:\xxx\target\debug\deps\libcrossbeam_utils-7899cf4a6805cf13.rmeta --extern diesel_derives=D:\xxx\target\debug\deps\diesel_derives-2ff439aa33fa564b.dll --extern lazy_static=D:\xxx\target\debug\deps\liblazy_static-f325b6318695618e.rmeta --extern libsqlite3_sys=D:\xxx\target\debug\deps\liblibsqlite3_sys-af0f6d14d96468bf.rmeta --extern log=D:\xxx\target\debug\deps\liblog-92e470b260bf4e9e.rmeta --extern r2d2=D:\xxx\target\debug\deps\libr2d2-781b0e95ae154f8d.rmeta --cap-lints allow -L D:\xxx/deps/openssl/msvc32/x86_64\lib -L native=D:\xxx\target\debug\build\libsqlite3-sys-3cf6271dd6dd2e9d\out` (exit code: 0xc0000409, STATUS_STACK_BUFFER_OVERRUN)
Meta
rustc 1.45.0-nightly (0862458da 2020-04-25)
binary: rustc
commit-hash: 0862458dad90a0d80827e22e3f86e33add6d847c
commit-date: 2020-04-25
host: i686-pc-windows-msvc
release: 1.45.0-nightly
LLVM version: 9.0
Activity
mati865 commentedon May 10, 2020
cc @nagisa @oli-obk
Could it be regression from #55617?
nagisa commentedon May 10, 2020
it is plausible if our redzone is not large enough, or if there are places where we forgot to add stack capacity checks.
Especially as the default primary stack size got reduced back to sanity…
That said, this needs a stacktrace and perhaps a MCVE.
nagisa commentedon May 10, 2020
Also, apparently it can mean many other things too https://devblogs.microsoft.com/oldnewthing/20190108-00/?p=100655
w93163red commentedon May 10, 2020
I tried to run with RUST_BACKTRACE=1, but it did not show additional information.
nagisa commentedon May 10, 2020
The stacktrace needs to be obtained with a debugger, as this is not a rust panic.
EDIT: I’ll try to reproduce myself.
w93163red commentedon May 10, 2020
Thanks for the quick reply~
Is there some guide I can follow through? Since it is a very large private project, it takes time to provide the MCVE... And also I notice that when I compiled this project on Mac, I did not encounter that two diesels are compiled at the same time, but in Windows:
I did not know if it related to this bug...
nagisa commentedon May 10, 2020
@mati865 They are using the rustc version from a couple of weeks ago (04-25) so it cannot be the stacker PR.
@w93163red can you please try with a more recent compiler version? I’m unable to reproduce when building diesel with
with rustc from on 2020-05-09.
As for the debugger, you should be able to just copy the failing command (which is shown in the "process did not execute successfully" message) and run it under a debugger of some sort. A debugger available in Visual Studio or
x64dbg(my preferred option on windows) or perhaps evengdbshould do okay to obtain a stacktrace.w93163red commentedon May 10, 2020
The latest version also failed.
I will try to use x64dbg to show some dump info.
mati865 commentedon May 10, 2020
@nagisa sorry, I should have looked at the date...
w93163red commentedon May 10, 2020
@nagisa I am not familiar with obtaining the stack trace...
Is this what you want?
3 remaining items
w93163red commentedon May 10, 2020
@retep998
If I understand correctly:
Am I right?
retep998 commentedon May 10, 2020
That is what I would do to obtain a backtrace with full symbols, yes.
ollie27 commentedon May 10, 2020
STATUS_STACK_BUFFER_OVERRUNis the error code you get from aborts. Given the screenshot contains:This is almost certainly an OOM abort which is all the more likely on a 32-bit host (
i686-pc-windows-msvc).w93163red commentedon May 10, 2020
My sys info: i7 8700 + 32 GB
Windows 10 pro 64 bits
retep998 commentedon May 10, 2020
Even though your PC is 64-bit and has lots of memory, you're still using a 32-bit Rust.
nagisa commentedon May 10, 2020
As of couple of days ago
stackerhas been integrated into rustc (and the default stack size has been reduced significantly) so technically we do have all of these things to consider as part ofstacker(even if the underlying implementation on Windows is using Fibers).That is why I thought it might be related to stack initially (but that cannot be true anymore because the rustc in question was just too old).
Also you'll notice that I linked that blog post above already.
w93163red commentedon May 10, 2020
Just ~230MB?
nagisa commentedon May 10, 2020
230MB is just the size of the allocation that eventually caused rustc to hit the memory limit for a 32-bit process. At the time this allocation occurred, the process likely already had somewhere around 3.something GB allocated.
Please try installing a
x86_64-pc-windows-msvcrustc and try compiling with that.retep998 commentedon May 10, 2020
It also has to be able to allocate that 230MB as a single contiguous block. If there's some fragmentation from earlier allocations then it can fail even if there is enough space otherwise.
w93163red commentedon May 11, 2020
For x86_64 msvc, it still complains the same result:
w93163red commentedon May 11, 2020
Thanks to @retep998 's help, a current workaround is using x64 rustc host to cross-compile 32 bit binary.
nagisa commentedon May 11, 2020
Closing as inactionable on our end.