Repository navigation
attempt to fix bun install hanging in codex - #19721
Jarred-Sumner wants to merge 17 commits into
Conversation
|
Updated 1:41 AM PT - May 19th, 2025
❌ @Jarred-Sumner, your commit 87a3132 has 1 failures in
🧪 To try this PR locally: bunx bun-pr 19721That installs a local version of the PR into your bun-19721 --bun |
b9263d8 to
e44468d
Compare
| if (Environment.isDebug or Environment.enable_asan) { | ||
| if (!log.lock.tryLock()) { | ||
| @panic("Cannot deinit the log while a thread is active"); | ||
| } | ||
| } | ||
| defer { | ||
| if (Environment.isDebug or Environment.enable_asan) { | ||
| log.lock.unlock(); | ||
| } | ||
| } |
There was a problem hiding this comment.
There's a potential issue in the lock handling during deinit(). The code panics if tryLock() fails, but the defer block unconditionally calls unlock() regardless of whether the lock was successfully acquired. This could lead to undefined behavior if the panic is caught or in future refactoring.
Consider modifying the code to only unlock if the lock was successfully acquired:
if (Environment.isDebug or Environment.enable_asan) {
const lock_acquired = log.lock.tryLock();
if (!lock_acquired) {
@panic("Cannot deinit the log while a thread is active");
}
defer if (lock_acquired) log.lock.unlock();
}This ensures the lock is only released if it was successfully acquired.
| if (Environment.isDebug or Environment.enable_asan) { | |
| if (!log.lock.tryLock()) { | |
| @panic("Cannot deinit the log while a thread is active"); | |
| } | |
| } | |
| defer { | |
| if (Environment.isDebug or Environment.enable_asan) { | |
| log.lock.unlock(); | |
| } | |
| } | |
| if (Environment.isDebug or Environment.enable_asan) { | |
| const lock_acquired = log.lock.tryLock(); | |
| if (!lock_acquired) { | |
| @panic("Cannot deinit the log while a thread is active"); | |
| } | |
| defer if (lock_acquired) log.lock.unlock(); | |
| } |
Spotted by Diamond
Is this helpful? React 👍 or 👎 to let us know.
a1a86c1 to
87a3132
Compare
|
I split this PR into 5 separate PRs, but none of them actually fix the issue impacting Codex. My current hunch there is a bug in our HTTP client, but I'm ont sure yet. Please follow along in #19755.
|
What does this PR do?
logger.Logwhich is supposed to be threadlocal but ExtractTarball is using the package manager's logger from inside the threadpool, which is not threadsafe.BUN_DISABLE_ATOMIC_RENAMEbe able to rule outrenameat2as the causeBUN_FEATURE_FLAG_DISABLE_INSTALL_INDEXto be able to rule out manifest cache installs as the causeHow did you verify your code works?