Skip to content

Backport #9250 to 4.0 - Fix memory pool corruption after allocation failure in FreeObjects::newBlock() - #9254

Merged
AlexPeshkoff merged 1 commit into
FirebirdSQL:v4.0-releasefrom
gabrieleciech:fix/newblock-exception-safety-4.0
Oct 30, 2026
Merged

AlexPeshkoff merged 1 commit into
FirebirdSQL:v4.0-releasefrom
gabrieleciech:fix/newblock-exception-safety-4.0

Conversation

@gabrieleciech

Copy link
Copy Markdown
Contributor

Backport of #9250 to v4.0-release.

Same change as in master: FreeObjects::newBlock() allocates the new extent before retiring the current one, so a failing newExtent() no longer drops the current extent's usage reference twice. The code differs from master only in style (no const on size/size1, existing exception specification kept).

No unit test: this branch has no Boost test suite. Verified with the scenario of the test from #9250 built against the common library of this branch (Release, Linux x64):

  • without the fix it crashes with SIGSEGV, with the fix it passes.

…allocation failure

When newExtent() throws (e.g. std::bad_alloc), the current extent has already
been retired with decrUsage() but currentExtent still points to it, so the next
call retires it again. Its usage count drops below the number of live blocks
and the extent (and the medium hunk holding it) can be reclaimed while still
in use, leading to crashes in unlinkBlocks()/SemiDoubleLink::remove().

Allocate the new extent first and retire the old one only after success.

Backport of FirebirdSQL#9250.
@AlexPeshkoff
AlexPeshkoff merged commit c6d3aec into FirebirdSQL:v4.0-release Oct 30, 2026
5 of 8 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants