memory/shared: fix static destruction order fiasco via nifty-counter idiom - #884
Draft
ahmed0mousa wants to merge 1 commit into
Draft
memory/shared: fix static destruction order fiasco via nifty-counter idiom#884ahmed0mousa wants to merge 1 commit into
ahmed0mousa wants to merge 1 commit into
Conversation
ahmed0mousa
requested review from
LittleHuba,
bemerybmw,
castler,
crimson11,
hoe-jo and
limdor
as code owners
August 10, 2026 09:13
ahmed0mousa
force-pushed
the
ahmo_fix_static_destruction_order
branch
2 times, most recently
from
August 10, 2026 12:12
bb82ce6 to
9a8994c
Compare
ahmed0mousa
marked this pull request as draft
August 10, 2026 12:12
ahmed0mousa
force-pushed
the
ahmo_fix_static_destruction_order
branch
from
August 11, 2026 12:28
9a8994c to
22ed784
Compare
…idiom MemoryResourceRegistry and SharedMemoryFactoryImpl were plain Meyer singletons (MeyerSingleton<T>::GetInstance()). ~SharedMemoryResource() accesses MemoryResourceRegistry::getInstance(), so if a client stores a std::shared_ptr<ISharedMemoryResource> in a static/long-lived context created before the registry's first use, that static could be destroyed after the registry, causing UB/crashes at shutdown. Both singletons now use score::os::StaticDestructionGuard (the nifty-counter idiom), matching the pattern already used by score::os::Mman. The guard for MemoryResourceRegistry is pulled into the public i_shared_memory_resource.h so any client holding a static shared_ptr<ISharedMemoryResource> is protected; the guard for SharedMemoryFactoryImpl stays internal to shared_memory_factory_impl.h to keep the public shared_memory_factory.h lightweight.
ahmed0mousa
force-pushed
the
ahmo_fix_static_destruction_order
branch
from
August 12, 2026 07:01
22ed784 to
3063470
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
MemoryResourceRegistry and SharedMemoryFactoryImpl were plain Meyer singletons (MeyerSingleton::GetInstance()). ~SharedMemoryResource() accesses MemoryResourceRegistry::getInstance(), so if a client stores a std::shared_ptr in a static/long-lived context created before the registry's first use, that static could be destroyed after the registry, causing UB/crashes at shutdown.
Both singletons now use score::os::StaticDestructionGuard (the nifty-counter idiom), matching the pattern already used by score::os::Mman. The guard for MemoryResourceRegistry is pulled into the public i_shared_memory_resource.h so any client holding a static shared_ptr is protected; the guard for SharedMemoryFactoryImpl stays internal to shared_memory_factory_impl.h to keep the public shared_memory_factory.h lightweight.
Depends-on: #896