Summary
AirSimNH/ProjectAirSim crashes with a SIGSEGV while retrying setParameter()/getParameter() for a PX4 parameter (COM_OBL_ACT), after the HIL MAVLink TCP connection to PX4 SITL had already started failing with socket send errors. Expected behavior: a stalled/unresponsive FCU parameter exchange should be handled as a timeout/error, not crash the whole process.
Environment
- ProjectAirSim binary:
Neighborhood-Linux-UE5.2-PAS_v0.2.0 (Linux)
- PX4: SITL, running in Docker with
network_mode: host (one PX4 instance per container, HIL over TCP)
- Reproduced while integrating a downstream PX4 adapter against this exact stack
Steps to reproduce
- Launch the ProjectAirSim binary natively; start PX4 SITL (Docker); publish a scene-load message using the ROS2 Node (HIL TCP connects, GPS lock, home position set).
- Restart the PX4 container (
docker restart) to force a clean TCP reconnect
- Re-publish the scene-load message a second time.
- The server log shows the HIL TCP connection failing to send:
[PX4Api] Exception sending messages to vehicle
[PX4Api] MavLinkConnectionImpl: Error sending message on connection 'hil', details: TcpClientPort socket send failed with error: 32
[PX4Api] Disconnecting mavlink vehicle
[PX4Api] SetNormalMode: putting PX4 in non-simulation mode via cmd
- Shortly after, during a parameter sync attempt for
COM_OBL_ACT, the process crashes:
setParameter() calling getParameter() for COM_OBL_ACT, try #6...
Signal 11 caught.
Malloc Size=262146 LargeMemoryPoolOffset=262162
CommonUnixCrashHandler: Signal=11
Failed to find symbol file, expected location:
".../AirSimNH-Linux-Shipping.sym"
Malloc Size=131160 LargeMemoryPoolOffset=393352
Malloc Size=131160 LargeMemoryPoolOffset=524536
Engine crash handling finished; re-raising signal 11 for the default handler. Good bye.
Segmentation fault (core dumped)
Additional context
Independently (via a separate MAVLink client and via MAVROS against the same PX4 instance), I've confirmed the PX4 SITL instance had stopped responding to all inbound command/parameter/mission requests at this point, while still sending outbound telemetry normally , so the FCU itself was in a degraded state by the time this crash happened. That degraded FCU state may be a separate/pre-existing issue, but regardless of its cause, setParameter()'s retry-then-crash behavior on a non-responding FCU looks like the actual bug worth fixing here.
Summary
AirSimNH/ProjectAirSimcrashes with aSIGSEGVwhile retryingsetParameter()/getParameter()for a PX4 parameter (COM_OBL_ACT), after the HIL MAVLink TCP connection to PX4 SITL had already started failing with socket send errors. Expected behavior: a stalled/unresponsive FCU parameter exchange should be handled as a timeout/error, not crash the whole process.Environment
Neighborhood-Linux-UE5.2-PAS_v0.2.0(Linux)network_mode: host(one PX4 instance per container, HIL over TCP)Steps to reproduce
docker restart) to force a clean TCP reconnectCOM_OBL_ACT, the process crashes:Additional context
Independently (via a separate MAVLink client and via MAVROS against the same PX4 instance), I've confirmed the PX4 SITL instance had stopped responding to all inbound command/parameter/mission requests at this point, while still sending outbound telemetry normally , so the FCU itself was in a degraded state by the time this crash happened. That degraded FCU state may be a separate/pre-existing issue, but regardless of its cause,
setParameter()'s retry-then-crash behavior on a non-responding FCU looks like the actual bug worth fixing here.