Encounter STATUS_STACK_BUFFER_OVERRUN when compiling diesel on windows 10

[w93163red]

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

[mati865]

cc @nagisa @oli-obk
Could it be regression from #55617?

[nagisa]

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]

Also, apparently it can mean many other things too https://devblogs.microsoft.com/oldnewthing/20190108-00/?p=100655

[w93163red]

I tried to run with RUST_BACKTRACE=1, but it did not show additional information.

[nagisa]

The stacktrace needs to be obtained with a debugger, as this is not a rust panic.

EDIT: I’ll try to reproduce myself.

[w93163red]

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]

@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

cargo build --release --no-default-features

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 even gdb should do okay to obtain a stacktrace.

[w93163red]

The latest version also failed.

I will try to use x64dbg to show some dump info.

[mati865]

@nagisa sorry, I should have looked at the date...

[w93163red]

@nagisa I am not familiar with obtaining the stack trace...
Is this what you want?

[nagisa]

That’s close, but there are a couple of issues:

1. The stack trace is not symbolized; don’t remember if x64dbg has a way to make it happen here, if there’s no way to make symbols to show up in x64dbg, you might need to try a different debugger;
2. The stack trace is for cargo, not the crashing rustc invocation.

[w93163red]

When only executing the command:

[retep998]

it is plausible if our redzone is not large enough, or if there are places where we forgot to add stack capacity checks.

STATUS_STACK_BUFFER_OVERRUN has nothing to do with stack sizes or stack capacities or redzones (Windows on x86_64 does not even have a redzone). Rather it indicates some sort of fatal condition was detected and it did a fail fast abort.

https://devblogs.microsoft.com/oldnewthing/20190108-00/?p=100655

The stack trace is not symbolized

You're not getting any symbols from an -msvc build unless you have the associated PDB files. Since rustup does not ship PDB files, you'll have to use a rustc built from source with debuginfo enabled if you want symbols.

That said, since the crash seems to be happening in a system dll, it is possible to get symbols from those although you need a debugger that supports the Windows symbol server stuff and I only know how to do that with Visual Studio's debugger.

[w93163red]

@retep998
If I understand correctly:

1. build a rustc with debuginfo enabled
2. run the above steps again with Visual Studio's debugger.
   Am I right?

[retep998]

That is what I would do to obtain a backtrace with full symbols, yes.

[ollie27]

STATUS_STACK_BUFFER_OVERRUN is the error code you get from aborts. Given the screenshot contains:

memory allocation of 234881024 bytes failed

This is almost certainly an OOM abort which is all the more likely on a 32-bit host (i686-pc-windows-msvc).

[w93163red]

STATUS_STACK_BUFFER_OVERRUN is the error code you get from aborts. Given the screenshot contains:

memory allocation of 234881024 bytes failed

This is almost certainly an OOM abort which is all the more likely on a 32-bit host (i686-pc-windows-msvc).

My sys info: i7 8700 + 32 GB
Windows 10 pro 64 bits

[retep998]

Even though your PC is 64-bit and has lots of memory, you're still using a 32-bit Rust.

[nagisa]

STATUS_STACK_BUFFER_OVERRUN has nothing to do with stack sizes or stack capacities or redzones (Windows on x86_64 does not even have a redzone). Rather it indicates some sort of fatal condition was detected and it did a fail fast abort.
https://devblogs.microsoft.com/oldnewthing/20190108-00/?p=100655

As of couple of days ago stacker has 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 of stacker (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]

Just ~230MB?

[nagisa]

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-msvc rustc and try compiling with that.

[retep998]

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]

For x86_64 msvc, it still complains the same result:

[w93163red]

Thanks to @retep998 's help, a current workaround is using x64 rustc host to cross-compile 32 bit binary.

[nagisa]

Closing as inactionable on our end.