rustc panicked when link.exe ran out of memory

[rtfeldman]

I saw "we would appreciate a bug report" in the trace, so here it is! The full terminal output after I ran cargo test: https://gist.github.com/rtfeldman/027a3550c21381bb7d36daa0613a453a

I don't have a small project that reproduces this, and the project where I encountered it is not public, so I can't link to it directly from here. (That said, I can absolutely invite anyone to the project who is interested in reproducing this bug - just let me know!)

Meta

rustc --version --verbose:

rustc 1.44.0 (49cae5576 2020-06-01)
binary: rustc
commit-hash: 49cae55760da0a43428eba73abcb659bb70cf2e4
commit-date: 2020-06-01
host: x86_64-pc-windows-msvc
release: 1.44.0
LLVM version: 9.0

[retep998]

I don't think this is related to your project. Just your system genuinely running out of memory and everything crashing and burning because it can't allocate any memory.

[ratijas]

Could've been a nice error instead of a panic, though. Usually runtimes and allocators reserve some memory for recovery purposes, or just hope that leftovers from the latest alloc system call are enough.

However, I'd say, this is low priority.

[ratijas]

Update.

thread '' panicked at 'failed to reserve stack space for exception handling', src\libstd\sys\windows\stack_overflow.rs:14:17

This one contradicts to what I've said earlier. Seems like this exception handler only allocated when it needs to, i.e. not in advance, thus it can't handle OOM.

[retep998]

Update.

thread '' panicked at 'failed to reserve stack space for exception handling', src\libstd\sys\windows\stack_overflow.rs:14:17

This one contradicts to what I've said earlier. Seems like this exception handler only allocated when it needs to, i.e. not in advance, thus it can't handle OOM.

That actually happens during thread startup. Whenever Rust spawns a thread it calls SetThreadStackGuarantee to ensure there is enough space to handle stack overflow errors. That said, it would be nice to print the actual error that occurs when SetThreadStackGuarantee fails instead of just having that fixed message. I assume during the process of setting the thread stack guarantee Windows commits those pages which were otherwise reserved, and errors if it fails to do so (because not enough memory).