Hardfault - USB MAVLink instance on disconnecting (ENOTCONN ISSUE)

Hi,

I had the same issue mentioned in the thread: Hard fault when switching comms link mentioned by @eagle_labs

Using v1.16.0 , I had debugged the root cause of this problem.
Issue:

  • cdcacm_autostart fails to stop the mavlink instance, creating use-after-free condition as @eagle_labs mentioned.,
  • mavlink_receiver.cpp line:3175, it just sleeps and retries the loop, causing the mem corruption.

Does any PR targeting this fix?
@JulianOes as you already part of this dicussion., I think we can move forward for this fix.

Thanks! So then the question is why does the mavlink stop call fail? Any idea why?

So far I could not reproduce this myself. I’m still looking for pointers how to make it happen.

I added some PX4_INFO and PX4_DEBUG lines and found why mavlink fails to stop.,

INFO [cdcacm_autostart] VBUS present → absent (state=2 protocol=1)
INFO [cdcacm_autostart] connected: VBUS lost, requesting MAVLink stop
INFO [cdcacm_autostart] MAVLink stop: exec command on /dev/ttyACM0 (state_connected VBUS-lost)
ERROR 139083441 MAVLink stop: dispatch failed (pid=-1 errno=128 Transport endpoint is not connected)
DEBUG 139583615 state_disconnecting
INFO [cdcacm_autostart] USB disconnect: serdis_main() start
serdis: Disconnected
INFO [cdcacm_autostart] USB disconnect: serdis_main() done

errno=128 (ENOTCONN) proves the USB transport is already physically gone before cdcacm even tries to dispatch. exec_builtin can’t spawn the task because the endpoint is dead.

But Mavlink receiver already has ENOTCONN handling.

In mavlink_receiver.cpp line 3174

if (nread == -1 && errno == ENOTCONN) { // Not connected (can happen for USB)
    usleep(100000);  // just sleeps and retries forever!
}

Mavlink receiver detects ENOTCONN but never stops — it just sleeps 100ms and loops back. This creates a zombie mavlink instance on a dead fd.

Here is the complete picture.

  1. USB unplugged → CDC/ACM marks ENOTCONN immediately
  2. exec_builtin(“mavlink stop”) fails with errno=128 because transport is dead
  3. Mavlink receiver catches ENOTCONN but just sleeps 100ms and loops forever (line 3174-3176) — zombie!
  4. Instance slot stays occupied → stale pointer when USB reconnects → crash

I think we need to enfore mavlink stop instead of sleep and loop.,

Can you try with these fixes?

They seem to have fixed similar issues but apparently are not in 1.16.

@RaghuAero hello? Have you tried this one?

Hey hi @JulianOes ., I was in-active for past couple of weeks., I am going to try and let you know.

Hi, With the changes mentioned in [BACKPORT v1.16] Try to fix potential mavlink segfaults on USB disconnect by julianoes · Pull Request #27727 · PX4/PX4-Autopilot · GitHub . It is having the same issue.

[hardfault_log] – 2026-07-07-08:56:23 Begin Fault Log –
System fault Occurred on: 2026-07-07-08:56:23
Type:Hard Fault in file:armv7-m/arm_hardfault.c at line: 173 running task: mavlink_rcv_if3
FW git-hash: 6ea3539157ca358c70a515878b77077af7d4611d
Build datetime: Jul 6 2026 12:55:35
Build url: localhost
Processor registers: from 0x30025e34
r0:0xffffffea r1:0x00000000 r2:0x00000010 r3:0x00000000 r4:0x3001d690 r5:0x00000164 r6:0x3001d7a8 r7:0x30023828
r8:0x30022000 r9:0x3001d6dc r10:0x00000000 r11:0x3001d734 r12:0x00000000 sp:0x30025f08 lr:0x0802efa1 pc:0x0802efd0
xpsr:0x61000000 basepri:0x00000080 control:0x00000004
exe return:0xffffffe9
Fault status registers: from NVIC
cfsr:0x00008200 hfsr:0x40000000 dfsr:0x00000000 mmfsr:0x00000000 bfsr:0x00000000 afsr:0x00000000 abfsr:0x00000000
IRQ stack:
top: 0x24000f80
sp: 0x24000f10 Valid
bottom: 0x24000c80
size: 0x00000300
Invalid Stack! (Corrupted TCB) Stack base: 0x24000c80 Stack size: 0x00000300
User stack:
top: 0x300261f0
sp: 0x30025f08 Valid
bottom: 0x30024f68
size: 0x00001288
Invalid Stack! (Corrupted TCB) Stack base: 0x30024f68 Stack size: 0x00001288
Interrupt sp memory region, stack pointer lies within stack

Can you send me the full hardfault from SD card as well as the px4 file and elf file that you’re using? That will help me debug this. The elf file needs to be the exact one that you used to reproduce.

From the git hash I also can’t tell exactly what you’re trying, so we really need to be really exact here.

Hi

Find the file here.