Always check the result of `pthread_mutex_lock`

[joboet]

Fixes #120147.

Instead of manually adding a list of "good" platforms, I've simply made the check unconditional. pthread's mutex is already quite slow on most platforms, so one single well-predictable branch shouldn't hurt performance too much.

[rustbot]

r? @Mark-Simulacrum

(rustbot has picked a reviewer for you, use r? to override)

[cbiffle]

Wow, thanks for beating me to this!

[Mark-Simulacrum]

r=me with commits squashed

[Mark-Simulacrum]

@bors r+

[bors]

:pushpin: Commit 8d708e55eff9026eb379fe409e9ecc0619962640 has been approved by Mark-Simulacrum

It is now in the queue for this repository.

[matthiaskrgr]

@bors rollup=iffy I suspect this fails here: https://github.com/rust-lang/rust/pull/120441#issuecomment-1913605791

[Urgau]

@matthiaskrgr I think that rollup failed because of https://github.com/rust-lang/rust/pull/120232. This PR doesn't modify anything that would cause the errors seen in the rollup.

[matthiaskrgr]

Hmm well I have been scratching my head at that failure for a bit, guess we can just leave both prs on iffy, just in case :sweat_smile:

[joboet]

I've seen these issues before (e.g. #103193). They only occur on some targets, while others using the same code work just fine... I suspect that this is a bug in the const-checking logic...

Either way, this PR should be fine (it really does not touch anything related to const). If it keeps on failing, I'll just add the attribute.

[bors]

:hourglass: Testing commit 8d708e55eff9026eb379fe409e9ecc0619962640 with merge 56e88c45eaa0fb8cde65c1f50ee7948416598440...

[bors]

:boom: Test timed out

[rust-log-analyzer]

A job failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

[ChrisDenton]

@bors retry macos timeout again

[matthiaskrgr]

@ChrisDenton im suspecting that this pr causes a deadlock while bootstrapping somehow, my rollup that contained it failed reproducibly for more than 5 times other prs have passed in the meantime

[ChrisDenton]

But it hung on the LLVM stage? It didn't even get to building rust? Built target llvm-reduce was the last message before the timeout.

[matthiaskrgr]

Maybe parts of bootstrap use parallelism and this used stuff of the pr? I dunnno... let's try to @bors rollup=never at least

[joboet]

@bors r- Errors are returned directly instead of through errno; the fail code does not work correctly (that cannot have caused the CI hangs, however).

[joboet]

I've fixed it now. I really should not have relied on memory here 🤦, it turns out pthread_mutex_lock directly returns error codes.

@rustbot ready

[Mark-Simulacrum]

@bors r+ rollup=never

[bors]

:pushpin: Commit 1df1ebf6add883bcd620c607da40cda3b0fcfc3d has been approved by Mark-Simulacrum

It is now in the queue for this repository.

[bors]

:hourglass: Testing commit 1df1ebf6add883bcd620c607da40cda3b0fcfc3d with merge 8c65ba0e66bdaffb6f85b4e4e148ade49ddb5e6c...

[rust-log-analyzer]

The job aarch64-gnu failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

[2998/3236] Building CXX object tools/llvm-mca/CMakeFiles/llvm-mca.dir/Views/BottleneckAnalysis.cpp.o
[2999/3236] Building CXX object tools/llvm-mca/CMakeFiles/llvm-mca.dir/Views/DispatchStatistics.cpp.o
[3000/3236] Building CXX object tools/llvm-mca/CMakeFiles/llvm-mca.dir/Views/InstructionInfoView.cpp.o
[3001/3236] Building CXX object tools/llvm-mca/CMakeFiles/llvm-mca.dir/Views/InstructionView.cpp.o
##[error]The runner has received a shutdown signal. This can happen when the runner service is stopped, or a manually started runner is canceled.
##[group]Clock drift check
  local time: Tue Jan 30 00:02:09 UTC 2024
  network time: Tue, 30 Jan 2024 00:02:09 GMT
##[endgroup]
---
[3048/3236] Building CXX object tools/llvm-pdbutil/CMakeFiles/llvm-pdbutil.dir/MinimalSymbolDumper.cpp.o
[3049/3236] Building CXX object tools/llvm-pdbutil/CMakeFiles/llvm-pdbutil.dir/llvm-pdbutil.cpp.o
[3050/3236] Building CXX object tools/llvm-pdbutil/CMakeFiles/llvm-pdbutil.dir/MinimalTypeDumper.cpp.o
[3051/3236] Linking CXX executable bin/llvm-opt-report
Session terminated, killing shell... ...killed.
##[error]The operation was canceled.

[bors]

:broken_heart: Test failed - checks-actions

[cbiffle]

So, that's quite strange. Am I reading that correctly -- we're getting a deadlock on aarch64-gnu bootstrapping?

Edit: Is it possible this is a load-dependent timeout firing on a runner, and it should just be reattempted? The log output sure looks like it failed during C++ compilation bits, which I wouldn't expect this change to affect.

[cbiffle]

On reflection, Linux does not even build the module being changed, so I'm pretty confident this is flake, and would retrigger the build if I knew how / had the permissions (not sure about the latter).

[cbiffle]

Well, let's see if this works.

@bors retry

[bors]

@cbiffle: :key: Insufficient privileges: not in try users

[cbiffle]

Yeah, that's what I figured.

@Mark-Simulacrum I'm pretty sure this is build flake, since Linux doesn't build the code changed in this PR (it uses the futex version) -- do you think it's worth retrying?

[Mark-Simulacrum]

@bors r+ rollup=never

Yes, let's try again.

[bors]

:bulb: This pull request was already approved, no need to approve it again.

• This pull request previously failed. You should add more commits to fix the bug, or use retry to trigger a build again.
• There's another pull request that is currently being tested, blocking this pull request: #120543