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.

Sign up for GitHub

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

Jump to bottom

Spurious access violation (exit code: 3221225477) when compiling libsyntax with MSVC #50604

Closed
kennytm opened this issue May 10, 2018 · 10 comments
Closed

Spurious access violation (exit code: 3221225477) when compiling libsyntax with MSVC #50604

kennytm opened this issue May 10, 2018 · 10 comments
Labels
A-spurious Area: Spurious failures in builds (spuriously == for no apparent reason) C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC O-windows-msvc Toolchain: MSVC, Operating system: Windows T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-infra Relevant to the infrastructure team, which will review and decide on the PR/issue.

Comments

@kennytm
Copy link
Member

kennytm commented May 10, 2018

Symptom: On MSVC builders (Windows), when compiling libsyntax in either stage0 or stage1, the compiler rustc will crash with exit code 3221225477 (= 0xc0000005 = access violation).

We suspect this is related to #50329 (merged at 2018-05-02T10:13:06Z).

Sample crash log 
error: Could not compile `syntax`.
Caused by:
  process didn't exit successfully: `C:\projects\rust\build\bootstrap/debug/rustc --crate-name syntax libsyntax\lib.rs --color always --error-format json --crate-type dylib --emit=dep-info,link -C prefer-dynamic -C opt-level=3 -C metadata=7ac7668085f2897f -C extra-filename=-7ac7668085f2897f --out-dir C:\projects\rust\build\i686-pc-windows-msvc\stage0-rustc\i686-pc-windows-msvc\release\deps --target i686-pc-windows-msvc -L dependency=C:\projects\rust\build\i686-pc-windows-msvc\stage0-rustc\i686-pc-windows-msvc\release\deps -L dependency=C:\projects\rust\build\i686-pc-windows-msvc\stage0-rustc\release\deps --extern bitflags=C:\projects\rust\build\i686-pc-windows-msvc\stage0-rustc\i686-pc-windows-msvc\release\deps\libbitflags-9ba1f7028730cd0a.rlib --extern log=C:\projects\rust\build\i686-pc-windows-msvc\stage0-rustc\i686-pc-windows-msvc\release\deps\liblog-001e68131969f2ec.rlib --extern rustc_errors=C:\projects\rust\build\i686-pc-windows-msvc\stage0-rustc\i686-pc-windows-msvc\release\deps\rustc_errors-ffee8b3fc130b2b1.dll --extern syntax_pos=C:\projects\rust\build\i686-pc-windows-msvc\stage0-rustc\i686-pc-windows-msvc\release\deps\syntax_pos-1048adc53f632b89.dll --extern rustc_data_structures=C:\projects\rust\build\i686-pc-windows-msvc\stage0-rustc\i686-pc-windows-msvc\release\deps\rustc_data_structures-3a7257003acd8e8b.dll --extern scoped_tls=C:\projects\rust\build\i686-pc-windows-msvc\stage0-rustc\i686-pc-windows-msvc\release\deps\libscoped_tls-49f5fac2ae1c97d0.rlib --extern serialize=C:\projects\rust\build\i686-pc-windows-msvc\stage0-rustc\i686-pc-windows-msvc\release\deps\serialize-f37b7ca68fe29329.dll --extern serialize=C:\projects\rust\build\i686-pc-windows-msvc\stage0-rustc\i686-pc-windows-msvc\release\deps\libserialize-f37b7ca68fe29329.rlib --extern rustc_target=C:\projects\rust\build\i686-pc-windows-msvc\stage0-rustc\i686-pc-windows-msvc\release\deps\rustc_target-63878e92b639df83.dll` (exit code: 3221225477)
command did not execute successfully: "C:\\projects\\rust\\build\\i686-pc-windows-msvc\\stage0/bin\\cargo.exe" "build" "--target" "i686-pc-windows-msvc" "-j" "4" "--release" "--locked" "--color" "always" "--features" "" "--manifest-path" "C:\\projects\\rust\\src/rustc/Cargo.toml" "--message-format" "json"
expected success, got: exit code: 101
thread 'main' panicked at 'cargo must succeed', bootstrap\compile.rs:1091:9
note: Run with `RUST_BACKTRACE=1` for a backtrace.

First seen on the following PRs:

cc #33434 (parent issue)
@kennytm kennytm added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. A-spurious Area: Spurious failures in builds (spuriously == for no apparent reason) T-infra Relevant to the infrastructure team, which will review and decide on the PR/issue. C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC labels May 10, 2018
@kennytm kennytm mentioned this issue May 10, 2018
Merged
@ishitatsuyuki
Copy link
Contributor

cc @Zoxc Can you try to reproduce?

@Zoxc
Copy link
Contributor

Zoxc commented May 10, 2018

I haven't seen this locally. Does it happen often?

@kennytm
Copy link
Member Author

kennytm commented May 10, 2018

As shown in the post, twice in the last 8 days so far. There are 3 other segfaults on Windows which might also be attributed here (#50000 (comment), #50418 (comment), #50466 (comment)).

@kennytm kennytm mentioned this issue May 11, 2018
Merged
alexcrichton added a commit to alexcrichton/rust that referenced this issue May 11, 2018
@alexcrichton
Rollup merge of rust-lang#50644 - kennytm:read-appveyor-dump, r=alexc…
576bf68 
…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
@kennytm
Rollup merge of rust-lang#50644 - kennytm:read-appveyor-dump, r=alexc…
73c7528 
…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
@kennytm
Rollup merge of rust-lang#50644 - kennytm:read-appveyor-dump, r=alexc…
42939c5 
…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>.)
@ishitatsuyuki
Copy link
Contributor

Have this occurred this week?

@kennytm
Copy link
Member Author

kennytm commented May 19, 2018

@ishitatsuyuki No

@kennytm kennytm mentioned this issue May 25, 2018
Merged
@paulirotta paulirotta mentioned this issue Aug 1, 2018
Open
@mati865 mati865 mentioned this issue Sep 20, 2018
Closed
@hmaarrfk hmaarrfk mentioned this issue Jan 3, 2019
Merged
5 tasks
@azriel91 azriel91 mentioned this issue May 13, 2019
Closed
@steveklabnik
Copy link
Member

It's been a while; has anyone seen this lately?

@jonas-schievink jonas-schievink added the O-windows-msvc Toolchain: MSVC, Operating system: Windows label Nov 26, 2019
@DhruvDh
Copy link

DhruvDh commented Feb 19, 2020 •
edited
Loading 

error: process didn't exit successfully: `target\release\dip_viewer.exe -f easy.txt` (exit code: 0xc0000005, STATUS_ACCESS_VIOLATION)

happens at this code when running on particular machines build with --release. (msvc stable and nightly)
Building without release gives -

thread 'main' panicked at 'assertion failed: `(left == right)`
  left: `0`,
 right: `1`', C:\Users\ddhamani\.cargo\registry\src\github.com-1ecc6299db9ec823\wgpu-native-0.4.2\src\hub.rs:120:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
error: process didn't exit successfully: `target\debug\dip_viewer.exe -f easy.txt` (exit code: 101)

but it works fine on my laptop. This happens due to missing something wgpu dynamically links against?

@kennytm
Copy link
Member Author

kennytm commented Feb 19, 2020 •
edited
Loading

@DhruvDh hi, could you file a new issue for that? This issue only tracks spurious failure from Rust's CI and thus unsuitable for problems in user code.

@DhruvDh
Copy link

DhruvDh commented Feb 19, 2020

sorry, I did not realize that.

@crlf0710
Copy link
Member

Now that libsyntax is now renamed and splitted and crates structure changed a lot since then, i'd suggest we just close this?

@kennytm kennytm closed this as completed Jun 15, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
A-spurious Area: Spurious failures in builds (spuriously == for no apparent reason) C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC O-windows-msvc Toolchain: MSVC, Operating system: Windows T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-infra Relevant to the infrastructure team, which will review and decide on the PR/issue.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
7 participants
@Zoxc @steveklabnik @kennytm @crlf0710 @jonas-schievink @ishitatsuyuki @DhruvDh