STM32CubeIDE ThreadX RTOS Proxy breaks when thread name length > 20 characters

[MZamu.1]

Environment:

• STM32CubeIDE version: 1.16.1

• MCU: STM32H753

• RTOS: Azure RTOS ThreadX

• Debug probe: ST-Link (V3)

• RTOS Proxy plugin:
  com.st.stm32cube.ide.mcu.externaltools.rtosproxy.win32_1.1.1.202408301240

• OS: Windows

---

Issue description:

RTOS-aware debugging for ThreadX breaks completely when at least one ThreadX thread name length exceeds ~20 characters.

ThreadX itself has no limitation on thread name length (thread name is CHAR *).
However, STM32CubeIDE RTOS-aware debug stops working if any thread name is longer than ~20 characters.

When this happens:

• RTOS thread list becomes incomplete or unusable

• Switching between threads is not possible

• Call stack for inactive threads is missing

• GDB console shows warnings like:

   

  warning: while parsing threads: not well-formed (invalid token)

  

   

RTOS-aware debugging works correctly only when all ThreadX thread names fit into a 20-byte buffer including the null terminator (maximum 19 visible characters).

The issue is 100% reproducible.

---

Steps to reproduce:

1. Create a ThreadX project in STM32CubeIDE

2. Create several ThreadX threads

3. Set one thread name longer than 20 characters
   (e.g. "Disk Manager Init Thread")

4. Start debug with RTOS-aware debug enabled

5. Result: RTOS thread list and RTOS debug functionality break

6. Shorten all thread names to ≤ 20 characters

7. Restart debug

8. Result: RTOS-aware debug works correctly

---

Additional observations:

• The problem does not depend on:

  • MCU type

  • number of threads

  • ThreadX configuration

• The issue appears to be inside RTOS Proxy implementation

• It looks like an internal fixed-size buffer / missing string length check

• Large qXfer:threads:read packets are supported, but offset/chunk handling is broken

• A single long thread name is enough to break the entire RTOS debug view

---

Expected behavior:

RTOS-aware debug should work regardless of ThreadX thread name length, or at least handle long names safely without breaking XML parsing and RTOS debug functionality.

---

Workaround:

Manually limit all ThreadX object names to ≤ 20 characters.

[Ghofrane GSOURI]

Hello @MZamu.1 

I used the latest version of STM32CubeMX6.16.1 and STM32CubeIDE 2.0.0 to reproduce the issue mentioned above and I found that  RTOS thread list and RTOS debug are working correctly.

As you can see in my screenshot there is an active “ThreadX Thread List” tab, it lists:
- "Disk Manager Init Threa" (truncated display of "Disk Manager Init Thread")
* Priority: 10
* State: RUNNING
-"System Timer Thread"
 * State: SUSPENDED
- "Idle"
* State: IDLE
The columns (Name, Priority, State, Run Count, Stack Start/End/Size, etc.) are all populated.

 

 

THX

Ghofrane

[MZamu.1]

Hello Ghofrane,

thank you for checking this.

However, I think there is a misunderstanding regarding the issue.

The problem is NOT the ThreadX Thread List UI view itself.

Indeed, the UI correctly shows truncated names (e.g. "Disk Manager Init Threa"),

and this part works as expected.

The issue occurs specifically in RTOS-aware debugging via GDB using RTOS Proxy,

i.e. during qXfer:threads:read communication between GDB and the proxy.

When at least one ThreadX thread name length is ≥ 20 characters (including the terminating '\0'),

RTOS Proxy generates malformed XML for qXfer:threads:read.

As a result:

- GDB reports: "warning: while parsing threads: not well-formed (invalid token)"

- `info threads` becomes unreliable or incomplete

- switching threads (`thread <N>`) fails or shows incorrect context

- call stacks for non-active threads cannot be retrieved

- in some cases RTOS Proxy crashes with "Invalid offset"

This is reproducible 100% of the time.

If all thread names are shortened to ≤ 19 characters (so that '\0' fits),

RTOS-aware debugging immediately works correctly again.

Important notes:

- This affects RTOS Proxy / GDB integration, not the UI thread list.

- The issue is independent of ThreadX itself.

- The same firmware works correctly on older setups before recent RTOS Proxy changes.

RTOS Proxy version used:

com.st.stm32cube.ide.mcu.externaltools.rtosproxy.win32_1.1.1.202408301240

Could you please try reproducing using:

- RTOS Proxy enabled

- GDB `info threads`

- at least one ThreadX thread name ≥ 20 characters

and observe qXfer:threads:read behavior?

Best regards,

Mihail