Skip to content

fix(posix): make pxh app map initialization thread-safe#27643

Open
katzfey wants to merge 1 commit into
mainfrom
pr-thread-safe-start
Open

fix(posix): make pxh app map initialization thread-safe#27643
katzfey wants to merge 1 commit into
mainfrom
pr-thread-safe-start

Conversation

@katzfey

@katzfey katzfey commented Jun 11, 2026

Copy link
Copy Markdown
Contributor

Solved Problem

Fixes a POSIX PX4 daemon race where multiple client handler threads can concurrently initialize the static Pxh::_apps map on first command execution.

Solution

Use pthread_once() to initialize the PX4 shell builtin app map exactly once before process_line() or tab completion accesses it. This prevents concurrent first-use calls from both entering init_app_map(_apps) and mutating the same static std::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, but pthread_once() more directly models the intended one-time initialization behavior and avoids locking after initialization completes. Eagerly initializing _apps during daemon startup would also avoid the race, but keeping initialization local to Pxh preserves 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(), and std::_Rb_tree internals, consistent with concurrent mutation of the static builtin app map during early daemon/client startup.

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.
@katzfey katzfey requested review from dirksavage88 and mrpollo June 11, 2026 20:24
@katzfey katzfey self-assigned this Jun 11, 2026
@github-actions github-actions Bot added kind:bug Something is broken or behaving incorrectly. scope:simulation SITL, Gazebo, jmavsim, lockstep, or simulated sensors. labels Jun 11, 2026
@github-actions

Copy link
Copy Markdown
Contributor

🔎 FLASH Analysis

px4_fmu-v5x [Total VM Diff: 0 byte (0 %)]
    FILE SIZE        VM SIZE    
 --------------  -------------- 
  +0.0%     +55  [ = ]       0    .debug_abbrev
  -0.0%      -2  [ = ]       0    .debug_info
  -0.0%     -13  [ = ]       0    .debug_line
   -85.7%      -6  [ = ]       0    [Unmapped]
    -0.0%      -7  [ = ]       0    [section .debug_line]
  +0.0%     +40  [ = ]       0    TOTAL

px4_fmu-v6x [Total VM Diff: 0 byte (0 %)]
    FILE SIZE        VM SIZE    
 --------------  -------------- 
  +0.0%     +55  [ = ]       0    .debug_abbrev
  -0.0%      -2  [ = ]       0    .debug_info
  -0.0%      -5  [ = ]       0    .debug_line
     +40%      +2  [ = ]       0    [Unmapped]
    -0.0%      -7  [ = ]       0    [section .debug_line]
  +0.0%     +48  [ = ]       0    TOTAL

Updated: 2026-06-11T20:34:33

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

kind:bug Something is broken or behaving incorrectly. scope:simulation SITL, Gazebo, jmavsim, lockstep, or simulated sensors.

Projects

Status: Todo

Development

Successfully merging this pull request may close these issues.

1 participant