[参考译文] CC2538：在 ZNP/Z-Stack 3.0.1中调试内存泄漏

您能否查看 Zigbee 已知问题和建议的修复 Wiki 页面？ processors.wiki.ti.com/.../Zigbee_Known_Issues_and_Proposed_Fixes

对于在 OSAL_Memory.c 中定义的其他存储器变量、您还可以将编译标志 OSALMEM_Metrics = true 添加到项目中、这些变量可用于监视堆。

此致、
Ryan

您好！

除了可以告诉你堆的当前大小和最大大小的 OSALMEM_METRICS=true 之外、我们还有 OSALMEM_Profiler=true、 它用已知的值填充未分配的堆、这样您就可以使用 IAR 存储器调试视图密切监视正在使用的存储器区域、您可以在整个 OSAL_Memory.c 中搜索这些编译标志以了解实现的详细信息。

Ryan、

是的、我已经阅读了该内容并应用了所有相关补丁。

Jason、

它可能是碎片、而不是泄漏。 对于我来说、使用6k (默认值)堆似乎不太可能、但我认为这是可能的。

我现在所做的是将堆增加到22k (我们有32k CC2550's)。 这应该让我花些时间来调查 启动器的#defines 我将证明重新启动应用程序的 Linux 端会导致这种情况(而不是说时间)。 然后尝试确定我想增加的分配大小。

我的主要怀疑者是 AF：注销(我们注销旧应用端点并在启动时注册新端点)或重新启动协调器模式。

尊敬的 Mathew：

您是否有要提供的更新？

此致、
Ryan

Ryan、

尚未完成。 增加堆大小为我们提供了足够的处理空间来处理这几个月的优先事项。 一旦我们有一些空闲时间、就会跟踪泄漏情况。

目前、我们的首要任务是解决 e2e.ti.com/.../673996这一更为关键的问题