Skip to content

Conversation

@TreeHunter9
Copy link
Contributor

Previously we assign value to shutdownSemaphore after shutdownThread is started, where it was already needed. So we can have situation where shutdownThread instantly leaving due to shutdownSemaphore == nullptr, and we are left with a server that can only be stopped with kill -9.
I think this problem was hidden behind fbguard timeout and it's really hard to reproduce due to nature of race conditions, but in a synthetic environment using sleep to emulate high load and process switching in OS it is easily reproducible.

Previously we assign value to shutdownSemaphore after shutdownThread is started, where it is already needed. So we can have situation where shutdownThread instantly leaving due to shutdownSemaphore == nullptr, and we are left with a server that can only be stopped with kill -9.
@dyemanov dyemanov merged commit b4e2ea4 into FirebirdSQL:master Jan 10, 2025
24 checks passed
@dyemanov
Copy link
Member

Should it be backported?

@TreeHunter9
Copy link
Contributor Author

Should it be backported?

I think so, this bug appears in at least v4 and v5 (haven't looked at v3 and more older versions).

dyemanov pushed a commit that referenced this pull request Jan 13, 2025
Previously we assign value to shutdownSemaphore after shutdownThread is started, where it is already needed. So we can have situation where shutdownThread instantly leaving due to shutdownSemaphore == nullptr, and we are left with a server that can only be stopped with kill -9.

Co-authored-by: Artyom Ivanov <[email protected]>
@TreeHunter9 TreeHunter9 deleted the master-fix-race-in-shutdown-thread-start branch January 14, 2025 06:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants