Re: [threadx-users] [help] Question about _tx_byte_allocate / _tx_byte_r

[<Itsuki.Kanno@xxxxxxxxxxxx>]

Dear Bill,


Thank you very much for your helpful response.

First, I need to correct my previous statement:
It should have been **“before `_tx_byte_release`, the reverse pointer in the block header is unexpectedly set to `TX_BYTE_BLOCK_FREE`, even though the block was not freed yet.”**
I apologize for the confusion.

In our application, we have confirmed that `_tx_byte_release` is never called twice on the same pointer before reallocation. The unexpected change occurs between `_tx_byte_allocate` and `_tx_byte_release`. This is why we are trying to understand whether this could still be an application-level issue or something else.

My assumption was that `_tx_byte_allocate` and `_tx_byte_release` are designed to be thread-safe, so if the application uses these APIs correctly, thread safety should be guaranteed. Is this assumption incorrect? Are there any specific precautions we should take when multiple tasks share a single byte pool?

Regarding the `memory` option in the `TX_DISABLE` macro:
Our current implementation does not include `memory` option. I plan to try adding it as you suggested. However, since the issue occurs very rarely in our environment and we are working under SIL(IEC 61508) certification, any modification to ThreadX macros requires a clear theoretical justification.
If you could share why adding `memory` option resolves the issue and under what conditions the problem could occur without it, that would be extremely helpful.

Your advice would help us ensure compliance and robustness under functional safety requirements.

Thank you again for your support.


Best regards,
KANNO, Itsuki

________________________________________
差出人: Bill Lamie <blamie@xxxxxxxxxxx>
送信日時: 2025年12月5日 2:57
宛先: ThreadX end-user questions
CC: Kanno, Itsuki (Itsuki.Kanno@xxxxxxxxxxxx); threadx-users-request@xxxxxxxxxxx
件名: RE: [help] Question about _tx_byte_allocate / _tx_byte_release behavior in ThreadX 6.1.1

blamie@xxxxxxxxxxx からメールを受け取る頻度は高くありません。これが重要である理由<https://aka.ms/LearnAboutSenderIdentification>

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

Hi Itsuki-san,

After a call to tx_byte_release, the reverse pointer should be TX_BYTE_BLOCK_FREE. If you are saying that you see this happen before tx_byte_release is called, that feels like an application problem where an allocated block might be used after it was released and rereleased.

Since you are not using optimization, I don’t believe it is related to that. However, you can apply the same fix to rule that out, e.g., make sure your TX_DISABLE macro in tx_port.h uses the “memory” option in the in-line assembly, e.g.:

#define TX_DISABLE                              asm volatile (" MRS %0,CPSR; CPSID if ": "=r" (interrupt_save) : "memory");

I still think the issue might be related to either using or rereleasing an already freed pointer…

I hope that helps!

Best regards,

Bill

From: threadx-users <threadx-users-bounces@xxxxxxxxxxx> On Behalf Of Itsuki.Kanno--- via threadx-users
Sent: Thursday, December 4, 2025 2:04 AM
To: threadx-users@xxxxxxxxxxx
Cc: Itsuki.Kanno@xxxxxxxxxxxx; threadx-users-request@xxxxxxxxxxx
Subject: [threadx-users] [help] Question about _tx_byte_allocate / _tx_byte_release behavior in ThreadX 6.1.1

Dear ThreadX community,


I am working with ThreadX version 6.1.1 on TI AM2431 (Cortex-R5 core only), using Arm Compiler for Embedded FuSa 6.16.2 with optimization level -O0.

We have a single static global byte pool shared by multiple tasks. Occasionally, under heavy load, we observe inconsistent pool information when using `_tx_byte_allocate` and `_tx_byte_release`.

Specifically:
- After a successful `_tx_byte_allocate`, the header of the allocated block appears correct.
- However, after `_tx_byte_release`, the reverse pointer in the block header is unexpectedly set to `TX_BYTE_BLOCK_FREE`, even though the block was not freed yet.
- Additionally, the "next block" pointer inside the same block sometimes changes to an old value from a previous allocation.
- This issue seems to occur right after `_tx_byte_pool_search` performs a block split during allocation.

My concern is whether this behavior could be related to GitHub Issue #334, which mentions pool corruption under `-O3` or `-O2` optimization. In our case, we are using `-O0`, so the conditions differ.

Could you please advise if this is a known issue in ThreadX 6.1.1 or if it is likely caused by our application code?

Thank you for your support.

Best regards,
KANNO, Itsuki
Yokogawa Electric Corp.
Yokogawa Products HQ Sensing Center Development Div.
Analyzer Development Dep. Software Sec. Gr.1
Email: Itsuki.Kanno@xxxxxxxxxxxx<mailto:Itsuki.Kanno@xxxxxxxxxxxx>
TEL: +81-70-1005-8039
M22-3, 9-32, Nakacho 2-chome, Musashino-shi, Tokyo 180-8750, Japan
-----
CONFIDENTIAL: This e-mail may contain information that is confidential or otherwise protected from disclosure and intended only for the party to whom it is addressed. If you are not the intended recipient, please notify the sender by return and delete this e-mail. You are hereby formally advised that any unauthorized use, disclosure or copying of this email is strictly prohibited and may be unlawful.