Repository navigation
mutex: lock-order checker compares latches within one environment only - #268
Merged
Merged
Conversation
… only A mutex index is relative to one environment's mutex region, so two environments created the same way hand out the same indices. The checker kept one per-thread stack of held indices and compared them regardless of environment. A thread that held a latch in one environment and took the same-numbered latch in another was reported as a self-deadlock (BDB2077/BDB2080), or as a rank inversion when the classes differed (BDB2084), and the environment panicked. The TCL replication harness hits this on every election in an --enable-diagnostic build. __rep_update_setup holds mtx_clientdb and the rep region latch (rep_backup.c:1110-1112) and calls __rep_nextfile, which sends a message. The send callback puts it into a queue database in a second environment, and that put takes the queue environment's mpool region latch, mutex 3, the same index as the client's rep region latch. A non-diagnostic build is clean, and so is the engine: these are two different latches. Record the ENV with each held entry. The order and same-latch checks compare only entries from the same environment, and release pops only the entry from the releasing environment. lock_order_check gains a two-env arm: hold env A's mpool region latch, take env B's, with an exit if the indices do not collide. On the dev box (Debian 12, --enable-diagnostic) master reports BDB2077 and the arm fails with SIGABRT; with this change it passes, and the control and lk_partitions=1 arms are unchanged.
This was referenced Nov 4, 2026
Contributor
Coccinelle convention checksNo new violations. ✅ Resolved since baseline (3) -- update dist/cocci/baseline.txt to lock these in. |
Contributor
ABI diff vs
|
s_chk_inclconfig requires db_config.h before any other include in a file that includes it. Found by the region-signature CI job, whose first step runs dist/s_validate.
MUTEX_LOCK returns DB_RUNRECOVERY from its caller when the environment is panicked, so it compiles only inside a function that returns int. gcc accepted the void function; clang on FreeBSD rejects it with -Wreturn-mismatch.
gburd
marked this pull request as ready for review
November 4, 2026 21:55
This was referenced Nov 4, 2026
gburd
added a commit
that referenced
this pull request
Nov 4, 2026
lock_order_check.c now includes db_int.h for the two-env arm (#268), and db_int.h includes dbinc/queue.h from src/. leak-run.sh builds each driver with only -I$BUILD, so the leak job failed with "dbinc/queue.h: No such file or directory" on master after #268 and on the v2026.10.7.3 release PR. The Makefile rule already has src/ in CPPFLAGS; this matches it. Verified on Debian 12 (--enable-debug --enable-diagnostic): every driver builds and lock_order_check passes all three arms. (cherry picked from commit 8ba0c85)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The lock-order checker (
--enable-diagnosticonly) compared mutex indices across environments. A mutex index is relative to one environment's mutex region, so two environments created the same way hand out the same indices. A thread that held a latch in one environment and took the same-numbered latch in another was reported as a self-deadlock, and the environment panicked.Who hit it. In a diagnostic build, every replication TCL test panicked at its first election.
__rep_update_setupholds the client's rep region latch (mutex 3,rep_backup.c:1112) and sends a message. The test transport's send callback puts the message into a queue database in a second environment, and that put takes the queue environment's mpool region latch, also mutex 3. These are two different latches, so the engine has no bug; the checker was wrong.Fix. Each held entry records its ENV. The order and same-latch checks compare only entries from the same environment, and release pops only the releasing environment's entry. Release builds compile none of this. The struct is thread-local, so the region signature is unchanged.
Tests (dev box, Debian 12,
--enable-diagnostic):lock_order_check, new two-env arm (hold env A's mpool latch, take env B's)lock_order_checkcontrol andlk_partitions=1armsThe two-env arm exits with an error if the two indices do not collide, so it cannot pass vacuously.
LTS.
mut_order.c,lock_order.handlock_order_check.care identical onlts/2026.10.7, so the backport is a cleancherry-pick -x.