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

[<Itsuki.Kanno@xxxxxxxxxxxx>]

Dear Bill,


Thank you for clarifying that the ThreadX IEC 61508 certification applies only to the generic C code and does not cover tx*.h and tx*.S assembly files. I appreciate this important detail.
So, the scope of ThreadX SIL 4 certification is indeed limited to the C code. That makes sense.

Regarding our issue, what we are observing is not only that the reverse pointer in the block header is set to TX_BYTE_BLOCK_FREE before `_tx_byte_release`, but also that the "next block" pointer in the same header changes to an old value. This indicates that memory corruption or unintended modification is occurring outside of the expected `_tx_byte_release` behavior. We have already confirmed that no other thread is calling `_tx_byte_release` on this block during this time.

We understand that optimization-related issues can occur, and as a next step, we will apply the change from the latest commit related to Issue #334:

#ifdef TX_ENABLE_FIQ_SUPPORT
#define TX_DISABLE                              asm volatile (" MRS %0,CPSR; CPSID if ": "=r" (interrupt_save) : : "memory", "cc");
#else
#define TX_DISABLE                              asm volatile (" MRS %0,CPSR; CPSID i ": "=r" (interrupt_save) : : "memory", "cc");
#endif

If you think it would be more efficient to discuss this directly, I am happy to reach out to you at **blamie@xxxxxxxxxxx**. Please let me know if that works best for you.

Thank you again for your support and guidance.


Best regards,
KANNO, Itsuki

________________________________________
差出人: Bill Lamie <blamie@xxxxxxxxxxx>
送信日時: 2025年12月5日 9:39
宛先: Kanno, Itsuki (Itsuki.Kanno@xxxxxxxxxxxx); threadx-users@xxxxxxxxxxx
CC: 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,

The tx_byte_allocate and tx_byte_release APIs are indeed thread-safe.  If you are confident the application is not using a freed block or releasing a free block multiple times, then there is a problem somewhere in the port that needs to be investigated further.  That said, I don't know of any existing issue that could cause this.

As for the TX_DISABLE macro, the "memory" option basically forces the GCC compiler to assume memory updates could have occurred during the in-line assembly, which means it will reload various data elements in case they were modified. Otherwise, the reload might be optimized out, resulting in stale values causing the issue #334.  Even though I don’t think this is the problem, I think you should still apply the change and see if it makes a difference.

One thing about the ThreadX IEC 61508 certification:  The ThreadX certification is over the generic C code and therefore does not cover the tx_port.h file (macro in question). It also doesn't cover the tx*.S assembly files. The application firmware's certification must cover these. The point being, a change to tx_port.h will not affect the generic ThreadX certification.

I hope that makes sense...  Please feel free to also reach out to me at blamie@xxxxxxxxxxx

Best regards,

Bill


-----Original Message-----
From: Itsuki.Kanno@xxxxxxxxxxxx <Itsuki.Kanno@xxxxxxxxxxxx>
Sent: Thursday, December 4, 2025 4:11 PM
To: Bill Lamie <blamie@xxxxxxxxxxx>; threadx-users@xxxxxxxxxxx
Cc: threadx-users-request@xxxxxxxxxxx
Subject: Re: [help] Question about _tx_byte_allocate / _tx_byte_release behavior in ThreadX 6.1.1

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.