fix(posix): make pxh app map initialization thread-safe#27643
Open
katzfey wants to merge 1 commit into
Open
Conversation
Pxh lazily initializes the builtin app map from client handler threads. Concurrent first commands can both enter init_app_map() and mutate the static std::map at the same time. Use pthread_once so the map is populated exactly once before process_line() or tab completion read it.
Contributor
🔎 FLASH Analysispx4_fmu-v5x [Total VM Diff: 0 byte (0 %)]px4_fmu-v6x [Total VM Diff: 0 byte (0 %)]Updated: 2026-06-11T20:34:33 |
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
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.
Solved Problem
Fixes a POSIX PX4 daemon race where multiple client handler threads can concurrently initialize the static
Pxh::_appsmap on first command execution.Solution
Use
pthread_once()to initialize the PX4 shell builtin app map exactly once beforeprocess_line()or tab completion accesses it. This prevents concurrent first-use calls from both enteringinit_app_map(_apps)and mutating the same staticstd::map.Changelog Entry
For release notes:
Bugfix: prevent POSIX PX4 daemon crash from concurrent shell app map initialization
Alternatives
A mutex around the
_apps.empty()/init_app_map()block would also serialize initialization, butpthread_once()more directly models the intended one-time initialization behavior and avoids locking after initialization completes. Eagerly initializing_appsduring daemon startup would also avoid the race, but keeping initialization local toPxhpreserves the existing lazy initialization behavior.Test coverage
Built successfully, runs on voxl2
Context
A downstream crash report showed a segfault with a backtrace through
Pxh::process_line(),init_app_map(), andstd::_Rb_treeinternals, consistent with concurrent mutation of the static builtin app map during early daemon/client startup.