Lock manager test failure

[Dimitry Sibiryakov]

Hello,

> /Users/runner/work/firebird/firebird/src/lock/tests/LockManagerTest.cpp:189: error: in "EngineSuite/LockManagerSuite/LockManagerTests/LockUnlockNoWaitTest": check lockFail.load() > 0u has failed [0 <= 0]


is this periodically appearing in CI build failure specific to MacOS ARM64 or
on other platforms it just has smaller probability?

--
WBR, SD.

[Alex Peshkoff]

Never seen on other platforms but I did not watch for it.

[Adriano dos Santos Fernandes]

This test is designed to have fails and in this env (only) it does not
sometimes.

This fact makes me think that there is some problem, and the problem
seems to not be in the test code.


Adriano

[Vlad Khorsun]

18.02.2026 13:08, Adriano dos Santos Fernandes:

The "failed" check is:

BOOST_CHECK_GT(lockFail.load(), 0u);

Shouldn't it be BOOST_CHECK_GE ?

Same for the next line:

BOOST_CHECK_GT(lockSuccess, 0u);

Regards,
Vlad

[Adriano dos Santos Fernandes]

The test starts 8 threads concurrently, each trying 10000 iterations
no-wait locking and unlocking the same key and fails are registered.

Do you really think that is normal that no fail could be registered in
this scenario?

It could be that in MacOS locks are serialized, but for me, this would
still mean the implementation is far from good.


Adriano

[Vlad Khorsun]

19.02.2026 3:08, Adriano dos Santos Fernandes:

I really see that code allows such result. Perhaps adding some delay while
lock is taken would make probability of collisions higher. But it will not
change the fact that this test should expect zero fails (or zero success).

> It could be that in MacOS locks are serialized, but for me, this would
> still mean the implementation is far from good.

Or it runs on single CPU, for example. If you expect that lock manager lock
will "fly" like light-weight mutex - I'll disappoint you, sorry.

In any case, you may try to improve the code. And correct the checks in tests.
BTW, it will be good to add descriptions in tests of what it expects and why.


Regards,
Vlad

[Alex Peshkoff]

Agreed. Luckily this should not seriously affect FB operation - under
real circumstances delay between enqueue/dequeue calls much bigger.

[Dmitry Yemanov]

19.02.2026 12:57, Alex Peshkoff wrote:
>
>
> Agreed. Luckily this should not seriously affect FB operation - under
> real circumstances delay between enqueue/dequeue calls much bigger.

The code like this:

if (LCK_lock(tdbb, lock, LCK_EX, LCK_WAIT))
LCK_release(tdbb, lock);

is not so rare in our codebase.


Dmitry

[Alex Peshkoff]

I see no danger for FB operation if no other locks took were taken
during this time-slice. BTW, an issue is with LCK_NOWAIT locks.

[Vlad Khorsun]

19.02.2026 14:54, Alex Peshkoff:

What exact issue you talk about ?

Regards,
Vlad

[Alex Peshkoff]

Subj :-)

Lock manager tests fails in LCK_NOWAIT case.
LockManagerTest.cpp:138
BOOST_AUTO_TEST_CASE(LockUnlockNoWaitTest)

[Vlad Khorsun]

19.02.2026 15:08, Alex Peshkoff:

I'm confused - do you consider the problem is in LM code or do you agree
that test uses not correct checks ? If former, please explain in more details.

Regards,
Vlad

[Alex Peshkoff]

I want to say that this test is kind of useless - even if due to
specific behavior of LM on Mac it fails (i.e. lock with no-wait
parameter never fails) it makes no big harm to FB functionality. I do
not under what does it test.

BTW, I see no problems with other tests in that file.