Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [threadx-users] [help] Question about _tx_byte_allocate / _tx_byte_release behavior in ThreadX 6.1.1
  • From: Bill Lamie <blamie@xxxxxxxxxxx>
  • Date: Thu, 4 Dec 2025 17:57:28 +0000
  • Accept-language: en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=px5rtos.com; dmarc=pass action=none header.from=px5rtos.com; dkim=pass header.d=px5rtos.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=uuFD6Jdq4cCBj1YD1PAe85j3uQCCDIVnW8uUr6QqrY0=; b=fphld3HbmmM0anPiNx+gGY3ZP19qDAD93SNXiA8trvUk9ztRrUiQadEftqtXNDvj1t9I5X+BV/qAHH5q5Pt2kUC9sWS0UjEY2RXlZJ4+DtFPC6X2Zbupeb1sZvEJoOzYD8h0qiSqocZDpUJTkeawffzwZFndXGhKvDF9hdKDEr4tSiOO2CWhjFBQ4j3lOkDIAjJkKCD4zK8M/2h794+jCN5KD8IXWf8LaoiIqmkGPSamBMfWjEZzAmWGIBUuZ06c6w8gH+XjvVxMq38osv4S6oJDZQbanugo+IdvBd6yfbcsJwFpE8r5Gut+58p3M1Ryt5uEPJ1IGs2Y3JXUJq07rA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=hoRIJ/uMOjXjPxSZKsr9uedBEcHkto0ce8t6MVgjlJ/36u1rU8VQo6o5UhweChIGKXpjGXLQuxH59ar6cl3hZhnJ8yS92h3bl1CTq6CbtSwmzeVszocpGZxAGFzahqoxMSK2BLsfqCaW9dYSoRyyT6lLJjBnKydu4wEEerHK3gUOX+7vHVkrxUZQNIpLtBtgAMiWZY1gVy+VIdckKM0mtQhFJQzXBB6910S3clK7PdDkubJQN6lSlPZd0pm86qTWej5j9zWuPvFBjpNBJmVDqW/f7oUYbCDIIAAt2lFdyxEn+mB7j/mqrdxiR/rVXcnLA3fb0raOd9ytDSuE0sym5A==
  • Delivered-to: threadx-users@xxxxxxxxxxx
  • List-archive: <https://www.eclipse.org/mailman/private/threadx-users/>
  • List-help: <mailto:threadx-users-request@eclipse.org?subject=help>
  • List-subscribe: <https://www.eclipse.org/mailman/listinfo/threadx-users>, <mailto:threadx-users-request@eclipse.org?subject=subscribe>
  • List-unsubscribe: <https://www.eclipse.org/mailman/options/threadx-users>, <mailto:threadx-users-request@eclipse.org?subject=unsubscribe>
  • Msip_labels: MSIP_Label_277a80f2-c852-488e-92a6-9c3bbdc34d5f_Enabled=True; MSIP_Label_277a80f2-c852-488e-92a6-9c3bbdc34d5f_SiteId=0da2a83b-13d9-4a35-965f-ec53a220ed9d; MSIP_Label_277a80f2-c852-488e-92a6-9c3bbdc34d5f_SetDate=2025-12-04T07:43:21.911Z; MSIP_Label_277a80f2-c852-488e-92a6-9c3bbdc34d5f_Name=Public; MSIP_Label_277a80f2-c852-488e-92a6-9c3bbdc34d5f_ContentBits=1; MSIP_Label_277a80f2-c852-488e-92a6-9c3bbdc34d5f_Method=Standard;
  • Thread-index: AQHcZPEJ6c0CD4QFKEejTQ9oIyzWeLURwSKg
  • Thread-topic: [help] Question about _tx_byte_allocate / _tx_byte_release behavior in ThreadX 6.1.1

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

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.

Back to the top