This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

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

Guru**** 614665 points
Other Parts Discussed in Thread: CC2550
请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/675353/cc2538-debugging-memory-leak-in-znp-z-stack-3-0-1

器件型号:CC2538

最近我们发现、在重新启动与 ZNP 多次连接的 Gateway 应用程序的 Linux 端时、模块可能会泄漏内存。 这种情况越来越严重、直到最终仅返回16个错误或模块无法重新启动协调器。

如何调试 OSAL 存储器分配来查找泄漏?

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    您能否查看 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这一更为关键的问题

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    关闭此主题、直至提供更多信息。

    此致、
    Ryan