Skip to content

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

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

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

Conversation

@gabrieleciech

Copy link
Copy Markdown
Contributor

Backport of #9250 to v5.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).

Includes the unit test CommonSuite/AllocSuite/AllocTests/MediumExtentAllocationFailure (src/common/classes/tests/AllocTest.cpp, Linux only), unchanged from #9250:

  • without the fix: memory access violation at address 0x0;
  • with the fix: passes; the full common_test 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.
Add a unit test that forces the allocation failure via RLIMIT_AS.

Backport of FirebirdSQL#9250.
@gabrieleciech gabrieleciech changed the title Fix double decrUsage of current extent in FreeObjects::newBlock() on … Backport #9250 to 5.0 - Fix memory pool corruption after allocation failure in FreeObjects::newBlock() Oct 30, 2026
@AlexPeshkoff
AlexPeshkoff merged commit ce00569 into FirebirdSQL:v5.0-release Oct 30, 2026
19 of 23 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