Skip to content

FileEncoder delayed error reporting is still broken #117254

Closed

Description

#94732 introduced a delayed error reporting scheme which was either buggy when it was merged or became buggy shortly after. The bug only surfaced as a variety of ICEs upon running out of disk space. In #115542 I tried to fix the problem by simplifying FileEncoder so that it was harder to lose track of the delayed error.

But it looks like somehow this is still broken.

The failures I'm looking at are all in this crater run: #104862 (comment) and they all look like https://crater-reports.s3.amazonaws.com/pr-104862/master%237db4a89d49a8ed3a5f79b6cc3d555696baa1bbc3/gh/LooMaclin.test_kafka_musl/log.txt

[INFO] [stderr]    Compiling serde_json v1.0.39
[INFO] [stderr] thread 'rustc' panicked at /rustc/7db4a89d49a8ed3a5f79b6cc3d555696baa1bbc3/compiler/rustc_serialize/src/opaque.rs:233:42:
[INFO] [stderr] LLVM ERROR: IO failure on output stream: No space left on device
[INFO] [stderr] error: could not compile `serde` (lib)

We are ICEing in MemDecoder now. The delayed error reporting is supposed to report errors and halt the built when we try to finalize writing out the file where we ran into an issue, but it looks like that isn't happening. We're going ahead to decode a result which was not completely written out, and we try to access at an offset beyond the end of the mmap'd file.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Assignees

Labels

C-bugCategory: This is a bug.I-ICEIssue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions