Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Spurious access violation on Windows #33434

Closed
alexcrichton opened this issue May 5, 2016 · 7 comments
Closed

Spurious access violation on Windows #33434

alexcrichton opened this issue May 5, 2016 · 7 comments
Labels
A-spurious Area: Spurious failures in builds (spuriously == for no apparent reason) C-bug Category: This is a bug. O-windows Operating system: Windows

Comments

@alexcrichton
Copy link
Member

http://buildbot.rust-lang.org/builders/auto-win-gnu-64-opt/builds/4086/steps/test/logs/stdio
https://gist.github.com/alexcrichton/847ad18aec0a73d342838e5d8ed683a7
#33086 (comment)

---- [run-pass] run-pass\macro-crate-does-hygiene-work.rs stdout ----

error: auxiliary build of "C:/bot/slave/auto-win-gnu-64-opt/build/src/test/auxiliary/macro_crate_test.rs" failed to compile: 
status: exit code: 3221225477
command: PATH="C:\bot\slave\auto-win-gnu-64-opt\build\obj\x86_64-pc-windows-gnu/stage2/bin;C:\bot\slave\auto-win-gnu-64-opt\build\obj\x86_64-pc-windows-gnu\stage2\bin;C:\bot\slave\auto-win-gnu-64-opt\build\obj\x86_64-pc-windows-gnu\llvm\Release\lib;C:\mingw-w64\x86_64-4.9.1-win32-seh-rt_v3-rev1\mingw64\bin;C:\Python27;C:\msys64\mingw64\bin;C:\msys64\usr\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0;C:\msys64\usr\bin;C:\python27;C:\python27\scripts;C:\program files (x86)\inno setup 5;C:\program files (x86)\CMake\bin;C:\Program Files (x86)\Windows Kits\8.1\Windows Performance Toolkit;C:\Program Files\Microsoft SQL Server\110\Tools\Binn;C:\Program Files (x86)\Microsoft SDKs\TypeScript\1.0" x86_64-pc-windows-gnu/stage2/bin/rustc.exe C:/bot/slave/auto-win-gnu-64-opt/build/src/test/auxiliary/macro_crate_test.rs -L x86_64-pc-windows-gnu/test/run-pass-fulldeps/ --target=x86_64-pc-windows-gnu --crate-type=dylib -L x86_64-pc-windows-gnu/test/run-pass-fulldeps\macro-crate-does-hygiene-work.stage2-x86_64-pc-windows-gnu.run-pass.libaux -C prefer-dynamic --out-dir x86_64-pc-windows-gnu/test/run-pass-fulldeps\macro-crate-does-hygiene-work.stage2-x86_64-pc-windows-gnu.run-pass.libaux --cfg rtopt -C rpath -O -L x86_64-pc-windows-gnu/rt
stdout:
------------------------------------------

------------------------------------------
stderr:
------------------------------------------

------------------------------------------

thread '[run-pass] run-pass\macro-crate-does-hygiene-work.rs' panicked at 'explicit panic', C:/bot/slave/auto-win-gnu-64-opt/build/src/tools/compiletest/src\runtest.rs:1595
note: Run with `RUST_BACKTRACE=1` for a backtrace.


failures:
    [run-pass] run-pass\macro-crate-does-hygiene-work.rs

test result: FAILED. 56 passed; 1 failed; 2 ignored; 0 measured

The exit code 3221225477 is 0xC0000005 in hex which correspond to an access violation. Basically this is a spurious segfault on Windows (I think).

I've seen this from time to time, but unfortunately it doesn't seem to reproduce on the same test so far nor have I ever seen it locally. Seems bad though!

@alexcrichton alexcrichton added O-windows Operating system: Windows A-spurious Area: Spurious failures in builds (spuriously == for no apparent reason) labels May 5, 2016
@alexcrichton
Copy link
Member Author

Failures like #33072 (comment) (full) make me think that this is some crazy thing because rm segfaulted. I could be wrong though.

@apasel422 apasel422 changed the title Spuroius access violation on Windows Spurious access violation on Windows May 5, 2016
@alexcrichton
Copy link
Member Author

One possible explanation may be OOM, although I have nothing to support that beyond a vague mention in a thread that is itself only vaguely related to this. Looking at a build which failed for this there were 3 builds on one Windows machine (the max concurrent) where one finished, another died, and the last was killed all at about the same time. The one which was killed was compiling LLVM (one file at a time), the one which died was in pretty tests. Neither of those are really that memory intensive and the machines have 16GB of memory which should in theory be more than enough...

Something to keep an eye out for I guess?

@matthiaskrgr
Copy link
Member

If this is the same as mentioned here https://randomascii.wordpress.com/2018/02/25/compiler-bug-linker-bug-windows-kernel-bug/ , I wonder if we could implement a workaround somehow.

alexcrichton added a commit to alexcrichton/rust that referenced this issue May 11, 2018
…richton

AppVeyor: Read back trace from crash dump on failure.

This is an attempt to debug spurious access violations on Windows (rust-lang#33434, rust-lang#50604). Thanks to rust-lang#50276, there should be minidumps to read when rustc segfault.

(The implementation is based on <https://github.com/springmeyer/travis-coredump/blob/master/test.bat>.)
kennytm added a commit to kennytm/rust that referenced this issue May 12, 2018
…richton

AppVeyor: Read back trace from crash dump on failure.

This is an attempt to debug spurious access violations on Windows (rust-lang#33434, rust-lang#50604). Thanks to rust-lang#50276, there should be minidumps to read when rustc segfault.

(The implementation is based on <https://github.com/springmeyer/travis-coredump/blob/master/test.bat>.)
kennytm added a commit to kennytm/rust that referenced this issue May 13, 2018
…richton

AppVeyor: Read back trace from crash dump on failure.

This is an attempt to debug spurious access violations on Windows (rust-lang#33434, rust-lang#50604). Thanks to rust-lang#50276, there should be minidumps to read when rustc segfault.

(The implementation is based on <https://github.com/springmeyer/travis-coredump/blob/master/test.bat>.)
@steveklabnik
Copy link
Member

It's been a while; are we still seeing this?

@Brooooooklyn
Copy link

Brooooooklyn commented Nov 21, 2020

I saw the same issue while implementing a NodeJS napi library: napi-rs/napi-rs#297

It can reproduce in https://github.com/napi-rs/package-template

  1. choco install node-lts -x86 -y -f
  2. refreshenv
  3. checkout napi-1-pre branch
  4. yarn install
  5. yarn build
  6. node simple-test.js

The reproduce step could be found here: https://github.com/napi-rs/package-template/blob/napi-1-pre/.github/workflows/CI.yaml#L189

You can also see Github actions output from napi-rs/package-template#86

@ChrisDenton
Copy link
Member

I'm no longer able to reproduce the original issue nor the other case (please correct me if you can). It's not clear if they're even related as a spurious access violation can be caused by any number of different things.

I'm minded to close this in favour of more specific issues. If anyone is experiencing 0xC0000005 (aka STATUS_ACCESS_VIOLATION) it would be particularly useful to open a new issue with a minimal (if possible) reproducible example using nightly.

@jieyouxu
Copy link
Member

jieyouxu commented Dec 6, 2024

Triage: I'm inclined to close this as well due to lack of repro and overly generic failures, in favor of more specific issues if people are still running into them.

@jieyouxu jieyouxu closed this as not planned Won't fix, can't repro, duplicate, stale Dec 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-spurious Area: Spurious failures in builds (spuriously == for no apparent reason) C-bug Category: This is a bug. O-windows Operating system: Windows
Projects
None yet
Development

No branches or pull requests

7 participants