Skip to content

Fix potential panics in Drop implementations in rustc_errors::lock#152447

Open
nuxtreact wants to merge 1 commit intorust-lang:mainfrom
nuxtreact:master
Open

Fix potential panics in Drop implementations in rustc_errors::lock#152447
nuxtreact wants to merge 1 commit intorust-lang:mainfrom
nuxtreact:master

Conversation

@nuxtreact
Copy link

Replace .unwrap() calls with error ignoring in Drop implementations for Handle and Guard structs to prevent panicking in destructors.

Panicking in Drop can lead to process abortion if it occurs during stack unwinding. This change makes the code more robust by ignoring errors from CloseHandle and ReleaseMutex during cleanup.

Fixes the FIXME comments about potential panics in drop handlers.

Replace .unwrap() calls with error ignoring in Drop implementations
for Handle and Guard structs to prevent panicking in destructors.

Panicking in Drop can lead to process abortion if it occurs during
stack unwinding. This change makes the code more robust by ignoring
errors from CloseHandle and ReleaseMutex during cleanup.

Fixes the FIXME comments about potential panics in drop handlers.
@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Feb 10, 2026
@rustbot
Copy link
Collaborator

rustbot commented Feb 10, 2026

r? @mati865

rustbot has assigned @mati865.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

  • Owners of files modified in this PR: compiler
  • compiler expanded to 66 candidates
  • Random selection from 13 candidates

// Ignore errors during drop to avoid panicking in a destructor.
// If CloseHandle fails, the handle will be leaked, but this is
// preferable to aborting the process.
let _ = CloseHandle(self.0);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it even possible for a valid handle to return an error when closing?

ReleaseMutex((self.0).0).unwrap();
// Ignore errors during drop to avoid panicking in a destructor.
// If ReleaseMutex fails, the mutex will remain locked, but this is
// preferable to aborting the process.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think keeping the mutex locked is preferable. Keeping the mutex locked would cause a deadlock if another rustc instance (or another thread of the same rustc instance in the case of parallel rustc) inside the same process attempts to print a diagnostic. A deadlock is much worse than a crash.

//! Note that this is currently only needed for allowing only one 32-bit MSVC
//! linker to execute at once on MSVC hosts, so this is only implemented for
//! `cfg(windows)`. Also note that this may not always be used on Windows,
//! only when targeting 32-bit MSVC.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Presuming this comment is accurate, I'm not sure how much time it's worth investing in fixing up the implementation here. 32-bit MSVC Windows is already a niche target and all of the panic/abort seem like they'd at worst be a slightly worse error report for something that has gone genuinely wrong (seems acceptable).

@mati865
Copy link
Member

mati865 commented Feb 11, 2026

@rustbot reroll

@rustbot rustbot assigned jackh726 and unassigned mati865 Feb 11, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants