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.

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

test_gc is very flaky #3537

Closed
thoughtpolice opened this issue Apr 19, 2024 · 2 comments
Closed

test_gc is very flaky #3537

thoughtpolice opened this issue Apr 19, 2024 · 2 comments
Labels
🐛bug Something isn't working test_flakes

Comments

@thoughtpolice
Copy link
Collaborator

test_git_backend::test_gc fails a relatively large amount of the time for me when I run the whole workspace, making cargo nextest run --workspace very difficult to use.

Note that I never see this when running solely this test and nothing else; my machine has 12 threads/6 cores, and nextest does well to saturate those cores, so I assume this is another concurrency bug that only happens under load.

--- STDOUT:              jj-lib::runner test_git_backend::test_gc ---

running 1 test
git version 2.44.0
test test_git_backend::test_gc ... FAILED

failures:

failures:
    test_git_backend::test_gc

test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 313 filtered out; finished in 0.45s


--- STDERR:              jj-lib::runner test_git_backend::test_gc ---
thread 'test_git_backend::test_gc' panicked at lib/tests/test_git_backend.rs:151:5:
assertion `left == right` failed
  left: {CommitId("2b77d9134466c287c377c8b1910ed109a14176e2"), CommitId("6dd9bc207f872d28eb07f0ace0ff88690c113a28")}
 right: {CommitId("2b77d9134466c287c377c8b1910ed109a14176e2"), CommitId("6dd9bc207f872d28eb07f0ace0ff88690c113a28"), CommitId("5081332820ba839700a42b13cca24ca23053d078")}
stack backtrace:
   0: rust_begin_unwind
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panicking.rs:645:5
   1: core::panicking::panic_fmt
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/panicking.rs:72:14
   2: core::panicking::assert_failed_inner
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/panicking.rs:342:17
   3: core::panicking::assert_failed
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/panicking.rs:297:5
   4: runner::test_git_backend::test_gc
             at ./tests/test_git_backend.rs:151:5
   5: runner::test_git_backend::test_gc::{{closure}}
             at ./tests/test_git_backend.rs:46:13
   6: core::ops::function::FnOnce::call_once
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/ops/function.rs:250:5
   7: core::ops::function::FnOnce::call_once
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/ops/function.rs:250:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
@thoughtpolice thoughtpolice added 🐛bug Something isn't working test_flakes labels Apr 19, 2024
@martinvonz
Copy link
Member

Is it reproducible enough for you that you think you can bisect it? Maybe it started happening after the recent upgrade of gix.

@yuja
Copy link
Collaborator

yuja commented Apr 19, 2024

Appears that it can fail if git gc doesn't pack refs for some reasons. I'll send a fix.

yuja added a commit to yuja/jj that referenced this issue Apr 19, 2024
Apparently, these gc() invocations rely on that the previous "git gc" packed
all refs so there are no loose refs to compare mtimes. If there were remaining
(or new?) loose refs, mtime comparison could fail. Let's add +1sec to
effectively turn off the keep_newer option.

Fixes jj-vcs#3537
yuja added a commit to yuja/jj that referenced this issue Apr 21, 2024
This addresses the test instability. The underlying problem still exists, but
it's unlikely to trigger user-facing issues because of that. A repo instance
won't be reused after gc() call.

Fixes jj-vcs#3537
yuja added a commit to yuja/jj that referenced this issue Apr 22, 2024
This addresses the test instability. The underlying problem still exists, but
it's unlikely to trigger user-facing issues because of that. A repo instance
won't be reused after gc() call.

Fixes jj-vcs#3537
@yuja yuja closed this as completed in 9f4a731 Apr 22, 2024
yuja added a commit to yuja/jj that referenced this issue May 23, 2024
yuja added a commit that referenced this issue May 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🐛bug Something isn't working test_flakes
Projects
None yet
Development

No branches or pull requests

3 participants