[参考译文] RTOS/LAUNCHXL-CC1310：任务上下文中的 FREE()导致内存损坏？

您好、Michael、

发生这种情况时、您能否共享您看到的寄存器转储？  您是否按照 常见问题解答中的步骤 使用寄存器转储获取堆栈反向跟踪？

[引用 user="Michael Moon "]将 printf 几乎放在任何地方，[/引用]

您是否使用标准 printf？  我不建议这样做。 这将对程序的时间安排产生重大影响(以及您看到的问题)、并可能导致行为看起来不一致。

建议改用 System_printf()(或 Log_print 变体之一)。

[引用 USER="Michael Moon "]已知 TI-RTOS 的 malloc/free 实现是否被破坏？[/QUERT]

我不知道。

您的系统配置使用什么堆？

Steve

您好、Steve、

是的、我已经尝试了该指南中的调试步骤、但是 CCS 拒绝更新 PC、SP、LR 寄存器。 有时、它会让我更改一个值、但另两个值不会接受新值。

具体的行为是、我可以单击该字段并输入新值、但当我按 Enter 或以其他方式取消对该字段的聚焦时、显示的值仍然是在我尝试更改它之前可见的旧值。 很明显、CCS 认为我可以编辑寄存器、但决定在它尝试实际使用新值后我不能编辑。

我在获得可用回扫时遇到的最大问题是0)上述拒绝更新 PC/SP/LR 的问题、1) CCS 无法通过无法识别的符号进行回扫、 和2) CCS 不能通过硬件异常中断进行回写跟踪(它只显示异常描述字、例如0xFFFFFFFD 作为返回地址、并在由于#1而没有符号时产生扼流圈)

#1是个问题、因为0x1000nnnn 存储器地址范围内的任何符号显然都没有可用的符号、并且我的反向跟踪经常会在此处出现。
我还必须进行一些挖掘(请参阅我的其他文章)以查找0x1001nnnn 范围的符号、我还没有找到 CCS 自动加载这些符号的方法、并且我必须在每次调试运行时手动加载这些符号。 (从 golde/CC13xx/rtos_rom.xem3中添加符号)

#2是个问题、因为我正在尝试找出硬件异常的原因-由于上面的#0、我甚至无法通过在 Hwi 触发之前将 SP 指向堆栈位置来绕过该问题。

此外、当异常发生时、SP 通常是非感应的、但当我手动检查堆栈的存储器块时、似乎在 TI-RTOS 中发生了深刻的事件-就像 TI-RTOS 内部函数本身溢出了堆栈缓冲区、然后返回一样。
我很少在系统和任务堆栈中找到对我自己代码的任何引用、当我这么做时、它似乎是一个完全无害的代码片段、可能已经从返回。
发生这种情况时、 LR 寄存器始终保存0x100xnnnn 范围内的地址-如果是0x1001、我至少可以从 RTOS_ROM.xem3中获取函数名称、但如果是0x1000、我无法找到中代码的任何源或符号 这部分 ROM。

它也不能帮助 golde/CC13xx/rtos_rom.xem3 (提供0x1001nnnn 范围的调试符号)中的文件/行号与 tirtos-2.21.00.06提供的源文件保持一致、因此即使我在 TI-RTOS 内部跟踪我的过程、 代码视图将指向注释和 ifdefs 以及空白行(当然还有随机代码)、有时会指向它认为位于其中的函数的几页。

我一直在使用 System_printf 而不是常规 stdlib printf、其中 System_flush 位于适当的位置、SysMin 中有一个大型缓冲区。 我本应该在那里做得更具体一些。

无论默认堆是什么、我的编译都使用、我的 cfg 仅具有 BIOS.heapSize = 0x800；。 我认为这意味着我正在使用 HeapMem。

无论如何、在将 malloc/free 对切换为静态缓冲器(作为一系列非常长的随机代码更改的一部分)后、我的固件已在整个周末运行而不会崩溃、而不是在启动后的20至30秒内崩溃。 这个问题似乎几乎肯定是由在任务上下文中使用 malloc/free 对引起的。

几年前、我在其他针对 cortex-m3的项目上做了大量工作、这些项目没有出现任何此类问题、并广泛使用 malloc/free -这就是为什么我甚至没有想象到、在2017年、这可能是我需要关注的问题。

您能告诉我您使用的是哪个版本的 TI-RTOS 吗？ 我看了你的其他线程、但我没有看到任何地方提到过它。 此外、哪个版本的 CCS？

根据您提供的各种说明、您似乎正在经历一个在存储器上进行某段代码输入的经典案例、而这种情况不应该发生。 例如、这可能会发生在损坏的指针上、然后指令会被该错误代码覆盖。 然后、当 PC 到达它时、您会遇到崩溃。

这种问题的一个症状是、当您添加打印语句或进行看似不相关的代码更改时、应用程序将突然开始工作。 问题是、在这种情况下、您只能"幸运"、因为坏代码仍在占用内存、以至于它不应触摸、它不会崩溃、因为该内存不再是 PC 正在执行的指令(例如)。  或者、由于不同的时序(即添加的打印语句)、它仍然在同一条指令上插入、但该指令已运行、因此您不会遇到崩溃。

不幸的是、在我看来、您好像在这里获得了幸运。

如果您再次看到崩溃、您可以尝试的一个不同之处是将返回地址(LR)的值放入 PC (而不是 LR 寄存器)中。

在执行 BIOS 常见问题解答主题中的步骤后、如果我没有看到堆栈跟踪、我发现这对我来说很有用。 将 LR 值放入 PC 寄存器会将我带回到代码中的实际问题点、以及在 CCS 中填充调用堆栈。

Steve