The spanning_regions/mixgld, v62001/gtm7843, v55000/gtm7073 and v61000/gtm7804 subtests
failed with the following symptoms.
%YDB-F-ASSERT, Assert failed in sr_port/mlk_shrblk_create.c line 93
for expression (0 == (bucket->usedmap & 1U))
%YDB-F-ASSERT, Assert failed in sr_port/mlk_shrblk_create.c line 176
for expression (0 == (bucket->usedmap & (1U << bitnum)))
Turns out this is an issue with the lock shrsub deletion algorithm in a recent commit to #297.
When deleting a lock shrsub, if the bucket where the subscript hashes has the HIGHBIT (bit 31)
set we do a linear search. But it is possible the subscript is found in a neighbor that is
within 31 adjacent buckets. If so, we should still clear the neighbor bit in this bucket's
usedmap. Only if the neighbor is found 31 or more buckets from the original bucket do we leave
the 31st bit untouched.
The spanning_regions/mixgld, v62001/gtm7843, v55000/gtm7073 and v61000/gtm7804 subtests failed with the following symptoms.
Turns out this is an issue with the lock shrsub deletion algorithm in a recent commit to #297.
When deleting a lock shrsub, if the bucket where the subscript hashes has the HIGHBIT (bit 31) set we do a linear search. But it is possible the subscript is found in a neighbor that is within 31 adjacent buckets. If so, we should still clear the neighbor bit in this bucket's usedmap. Only if the neighbor is found 31 or more buckets from the original bucket do we leave the 31st bit untouched.