• 状态
  • 已锁定 已锁定
  • 回复 16 回复
  • 订户 0 订户
  • 视图 876 视图
  • 用户 0 会员在此处
选项
选项
相关

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.

[参考译文] CC2652R7：malloc 内存分配失败||堆已满

admin
Guru**** 2943350 points

Other Parts Discussed in Thread: SYSCONFIG, CC2652R7

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1337031/cc2652r7-malloc-memory-allocation-fails-heap-is-getting-full

器件型号：CC2652R7
主题中讨论的其他器件：SysConfig、

您好  

我在 运行时使用 malloc 尝试为我们的线程中的两个缓冲区分配23KB 的内存。  

在释放先前的存储器后、我们将为两个缓冲区重新分配相同的23KB

以下堆大小的函数已包含在我们的代码中、

iCall_heapStats_t 统计信息；
iCall_getHeapStats (&stats)；
gcam_printf (logd、"Heap stats：总堆大小：%lu、最大可用大小：%lu "\
"总可用大小：%lu\r\n "，
stats.totalSize、
stats.largestFreeSize、
stats.totalFreeSize)；

以下是分配和释放的日志。 在第6次迭代中、我们无法分配内存、并且 会记录 RS_ENOMEM 错误

堆统计:总堆大小: 93808,最大可用大小: 67040总可用大小: 68996
句柄@2000557c 大小2344 size_handle 4
堆统计:总堆大小: 93808,最大可用大小: 43524总可用大小: 45480
手柄@20005578尺寸23504 size_handle 4

FREE 后的 handle_deinit @00000000
FREE 后的 handle_deinit @00000000
堆统计:总堆大小: 93808,最大可用大小: 67040总可用大小: 69404
句柄@2000557c 大小2344 size_handle 4
堆统计:总堆大小: 93808,最大可用大小: 43524总可用大小: 45888
手柄@20005578尺寸23504 size_handle 4

FREE 后的 handle_deinit @00000000
FREE 后的 handle_deinit @00000000
堆统计:总堆大小: 93808,最大可用大小: 67040总可用大小: 70092
句柄@2000557c 大小2344 size_handle 4
堆统计:总堆大小: 93808,最大可用大小: 43524总可用大小: 46576
手柄@20005578尺寸23504 size_handle 4

FREE 后的 handle_deinit @00000000
FREE 后的 handle_deinit @00000000
堆统计:总堆大小: 93808,最大可用大小: 67040总可用大小: 106800
句柄@2000557c 大小2344 size_handle 4
堆统计:总堆大小: 93808,最大可用大小: 43524总可用大小: 83284
手柄@20005578尺寸23504 size_handle 4

FREE 后的 handle_deinit @00000000
FREE 后的 handle_deinit @00000000
堆统计:总堆大小: 93808,最大可用大小: 47024总可用大小: 143508
句柄@2000557c 大小2344 size_handle 4
堆统计:总堆大小: 93808,最大可用大小: 23508总可用大小: 119992
手柄@20005578尺寸23504 size_handle 4

FREE 后的 handle_deinit @00000000
FREE 后的 handle_deinit @00000000
堆统计:总堆大小: 93808,最大可用大小: 46872总可用大小: 160480
句柄@2000557c 大小2344 size_handle 4
堆统计:总堆大小: 93808,最大可用大小: 23356总可用大小: 136964
手柄@20005578尺寸23504 size_handle 4

发生 RS_ENOMEM、

在这里、我们将进行释放、并且仅尝试为什么仍然有堆内存未被释放？

自由(手柄)；
句柄= NULL；

您可以在此处帮助我们并告诉我们可以解决此问题的方法吗？

  • 0
    TI__Guru**** 2943350 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好！

    感谢您与我们联系。

    我有几个问题可以很好地理解您的情况：

    • 您能否指定正在使用的示例和 SDK 版本？
    • 您能否帮助了解为什么动态分配用于如此大的缓冲区、而不是静态分配？ 我特别好奇、因为您提到会重复分配相同大小的缓冲区。  
    • 您能否指定用于分配和释放存储器的 API 函数？ 我本来希望你使用 iCall_malloc ()和 iCall_free ()，但似乎没有。

    此致、

  • 0
    TI__Guru**** 2943350 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好  

    SDK 版本： simplelink_cc13xx_cc26xx_sdk_7_10_01_24

    1.之前我使用过 //*handle = malloc (1 * 23k)；

    根据您的命令、我进行了如下更改、

     *handle = iCall_malloc (23k)；

    但我仍然面临一个问题

    2.我们使用这个是因为我们的要求和顺序  

  • 0
    TI__Guru**** 2943350 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好！

    谢谢您告诉我。

    对我来说,你第一次测试的问题是, Total Free Size 持续增长-甚至超过了 Total Heap Size 的值。 在使用 iCall_malloc 时、您仍然遇到相同的问题吗？
    如果是、您能否使用 ROV 检查它是否提供相同的值？ (使用 ROV 的"heap"段、有关 ROV 的详细信息、请参阅此处 https://software-dl.ti.com/simplelink/esd/simplelink_cc13xx_cc26xx_sdk/7.10.00.98/exports/docs/ble5stack/ble_user_guide/html/ble-stack-5.x-guide/debugging-index.html?highlight=icall_heapstats_t#ti-rtos-object-viewer)

    导致分配失败的问题实际上是意料之中的，因为最大的可用空间小于您尝试分配的空间。 我们可以讨论解决最后一个问题的方法、但我更希望我们先解决另一个问题。

    此致、

  • 0
    TI__Guru**** 2943350 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好  

    是的。 我们甚至在使用您建议的函数时也会遇到这个问题、

    发生问题时、您是否询问以下设置？

  • 0
    TI__Guru**** 2943350 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    在这种情况下、上下文值不会更改。

    我是否遵循了您期望的正确做法？

  • 0
    TI__Guru**** 2943350 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    堆统计:总堆大小: 93808,最大可用大小: 23044总可用大小: 200088

    以上是堆崩溃前的最后一次打印

    您能检查一下吗、告诉我们

  • 0
    TI__Guru**** 2943350 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好！

    我可以问一下是否启用了 HeapMem 吗？ 看来情况并非如此。 我建议您启用它、以便您可以获得更多调试信息。

    步骤如下：

    1- Open SysConfig > TI RTOS > BIOS > Default Heap Settings 并将"Default Memory Heap Type"设置为"HeapMem"。 将 HeapSize 设置为0x16E00 (~93808)。

    2-构建和刷写代码

    3-您应该在 ROV 中有一个新视图、称为"HeapMem"

    4-再次运行您的程序,并在"Detailled "和"Freelist"视图中监控"HeapMem"的值

    它应该是这样的：

    此致、

  • 0
    TI__Guru**** 2943350 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好  

    我按照 您提供的步骤操作、但我面临以下问题  

    "../cc13x2x7_cc26x2x7_app_tirtos7.cmd"、第286行：错误#10099-D：程序无法装入可用内存、或者该段包含一个需要无法为此段生成的 trampoline 的调用站点。 针对段".stack"大小0x1fb8运行对齐失败。 可用存储器范围：
    SRAM 大小：0x23021未使用：0x29c9最大穿孔：0x1f28
    错误#10010：链接期间遇到错误；未生成"pnrj_gcam_CC2652r7.out"
    tiarmclang：错误：tiarmlnk 命令失败、退出代码1 (使用-v 查看调用)
    gmake[1]：***[pnrj_gcam_CC2652R7.out]错误1
    gmake：***[全部]错误2
    Makefile：221：目标"全部"的配方失败

    ****构建完成****

    但我分析的另一个推理是、当我分配较少的内存时、构建成功、但电路板未能正常启动。  

    当我们启用这个 HeapMem 时、还有其他需要注意的事情吗？

  • 0
    TI__Guru**** 2943350 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好！

    感谢您告诉我-减少分配给堆的内存量以使程序正常链接是正确的做法。 不过，我感到意外的是，这项计划在事后仍未能奏效。 我从这个问题得到的最接近的是、实际上程序在用更新的图像重新刷写电路板后进入了错误环路。 关闭调试会话并重启器件、以"修复"问题。
    为了继续分析、我建议参考以下内容-如果尚未这样做- https://software-dl.ti.com/simplelink/esd/simplelink_cc13xx_cc26xx_sdk/7.40.00.77/exports/docs/ble5stack/ble_user_guide/html/ble-stack-5.x-guide/debugging-index.html#debugging-common-heap-issues

    说实话、我非常确定这里发生了什么、即使我没有所有的要素来证明它、我也愿意提供我的分析。
    我的理论是,你正在遭受内存碎片。 在分配不同大小的内存的系统中很可能会出现此问题。 在您的情况下、考虑到分配的大小、该问题很快会导致一些副作用。
    有相当多的文献讨论这个问题、如果您有兴趣、我可以进一步详细说明。

    解决此问题的一种常见方法是对重复的相同大小的分配使用静态分配。 我想我在之前的一封信中建议过这一点、但我理解这可能不是您的解决方案-如果您希望我进行开发、请在这里告诉我。

     您可能需要考虑的其他因素包括：

    • 禁用大型(23 KB)分配以确保程序的其他部分不会导致内存泄漏。 这种内存泄漏可能会加快内存碎片的速度。
    • 尝试同时分配和释放23KB 表(并连续多次)。 如果仍然发生存储器碎片、则可能还有我们到目前为止尚未考虑的其他元素在发挥作用

    我希望这将有所帮助、

    此致、

  • 0
    TI__Guru**** 2943350 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好  

    请根据您的建议找到结果、

    • 禁用大型(23 KB)分配以确保程序的其他部分不会导致内存泄漏。 这种内存泄漏可能会加快内存碎片的速度。  这是没有问题的。
    • 尝试同时分配和释放23KB 表(并连续多次)。 如果存储器碎片仍然存在、那么可能存在我们到目前为止尚未考虑的其他元素->即使我已经检查过、也没有问题。 我在一个循环尝试了50次,没有问题。 请在下面找到此案例的日志

    分配前的堆统计:总堆大小: 93808,最大可用大小: 70376总可用大小: 70424

    1 . 地址0xA84A28870BC1寄存器 STS 1
    分配后的堆统计:总堆大小: 93808,最大可用大小: 70376总可用大小: 70424

    已初始





    化 堆统计释放后:总堆大小: 93808,最大可用大小: 70376总可用大小: 70424 ID 地址：0xCC037BDD0B4F 分配前的堆统计:总堆大小: 93808,最大可用大小: 45616总可用大小: 68416 RP 地址：0x4981996939BD 分配后的堆统计：总堆大小：93808、最大可用大小：45616总可用大小：68416 高级设置0启用 释放后的堆统计:总堆大小: 93808,最大可用大小: 45616总可用大小: 68416 启用高级设置1 分配前的堆统计:总堆大小: 93808,最大可用大小: 45664总可用大小: 68460 分配后的堆统计:总堆大小: 93808,最大可用大小: 45664总可用大小: 68460 释放后堆统计:总堆大小: 93808,最大可用大小: 45664总可用大小: 68460 分配前的堆统计:总堆大小: 93808,最大可用大小: 45664总可用大小: 68492 分配后的堆统计:总堆大小: 93808,最大可用大小: 45664总可用大小: 68492 释放后堆统计:总堆大小: 93808,最大可用大小: 45664总可用大小: 68492 分配前的堆统计:总堆大小: 93808,最大可用大小: 45664总可用大小: 68492 分配后的堆统计:总堆大小: 93808,最大可用大小: 45664总可用大小: 68492 释放后堆统计:总堆大小: 93808,最大可用大小: 45664总可用大小: 68492 分配前的堆统计:总堆大小: 93808,最大可用大小: 45664总可用大小: 68492 分配后的堆统计:总堆大小: 93808,最大可用大小: 45664总可用大小: 68492 释放后堆统计:总堆大小: 93808,最大可用大小: 45664总可用大小: 68492 分配前的堆统计:总堆大小: 93808,最大可用大小: 45664总可用大小: 68492 分配后的堆统计:总堆大小: 93808,最大可用大小: 45664总可用大小: 68492 释放后堆统计:总堆大小: 93808,最大可用大小: 45664总可用大小: 68492 分配前的堆统计:总堆大小: 93808,最大可用大小: 45664总可用大小: 68492 分配后的堆统计:总堆大小: 93808,最大可用大小: 45664总可用大小: 68492 释放后堆统计:总堆大小: 93808,最大可用大小: 45664总可用大小: 68492 分配前的堆统计:总堆大小: 93808,最大可用大小: 45664总可用大小: 68492 分配后的堆统计:总堆大小: 93808,最大可用大小: 45664总可用大小: 68492 释放后堆统计:总堆大小: 93808,最大可用大小: 45664总可用大小: 68492 分配前的堆统计:总堆大小: 93808,最大可用大小: 45664总可用大小: 68492 分配后的堆统计:总堆大小: 93808,最大可用大小: 45664总可用大小: 68492 释放后堆统计:总堆大小: 93808,最大可用大小: 45664总可用大小: 68492 分配前的堆统计:总堆大小: 93808,最大可用大小: 45664总可用大小: 68492 分配后的堆统计:总堆大小: 93808,最大可用大小: 45664总可用大小: 68492 释放后堆统计:总堆大小: 93808,最大可用大小: 45664总可用大小: 68492 分配前的堆统计:总堆大小: 93808,最大可用大小: 45664总可用大小: 68492 分配后的堆统计:总堆大小: 93808,最大可用大小: 45664总可用大小: 68492 释放后堆统计:总堆大小: 93808,最大可用大小: 45664总可用大小: 68492 分配前的堆统计:总堆大小: 93808,最大可用大小: 45664总可用大小: 68492 分配后的堆统计:总堆大小: 93808,最大可用大小: 45664总可用大小: 68492 释放后堆统计:总堆大小: 93808,最大可用大小: 45664总可用大小: 68492 分配前的堆统计:总堆大小: 93808,最大可用大小: 45664总可用大小: 68492 分配后的堆统计:总堆大小: 93808,最大可用大小: 45664总可用大小: 68492 释放后堆统计:总堆大小: 93808,最大可用大小: 45664总可用大小: 68492 分配前的堆统计:总堆大小: 93808,最大可用大小: 45664总可用大小: 68492 分配后的堆统计:总堆大小: 93808,最大可用大小: 45664总可用大小: 68492 释放后堆统计:总堆大小: 93808,最大可用大小: 45664总可用大小: 68492 分配前的堆统计:总堆大小: 93808,最大可用大小: 45664总可用大小: 68492 分配后的堆统计:总堆大小: 93808,最大可用大小: 45664总可用大小: 68492 释放后堆统计:总堆大小: 93808,最大可用大小: 45664总可用大小: 68492 分配前的堆统计:总堆大小: 93808,最大可用大小: 45664总可用大小: 68492 分配后的堆统计:总堆大小: 93808,最大可用大小: 45664总可用大小: 68492 释放后堆统计:总堆大小: 93808,最大可用大小: 45664总可用大小: 68492 分配前的堆统计:总堆大小: 93808,最大可用大小: 45664总可用大小: 68492 分配后的堆统计:总堆大小: 93808,最大可用大小: 45664总可用大小: 68492 释放后堆统计:总堆大小: 93808,最大可用大小: 45664总可用大小: 68492 分配前的堆统计:总堆大小: 93808,最大可用大小: 45664总可用大小: 68492
  • 0
    TI__Guru**** 2943350 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好！

    感谢您提供更多信息。

    感谢您确认没有内存泄漏。

    关于第二项测试：

    • 从正面看,我看到"总自由尺码"现在似乎是正确的-即它的价值没有持续增长,并保持在预期的区域。
    • 但是、我不确定存储器分配是否正确。 在分配缓冲区之前和之后、堆统计信息似乎是相同的。 我可以请您仔细检查一下吗？

    此致、

  • 0
    TI__Guru**** 2943350 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好  

    我将确认先前的日志位于裸机代码中、并且我使用 for 循环  

    但我们的项目情形不同于

    您能告诉我们，问题是由于可用空间增加而导致的，还是内存未正确释放？

    可能是什么原因？  

  • 0
    TI__Guru**** 2943350 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好！

    我认为目前有两个因素--可能是相关的，也可能不相关。

    1-在您提供的第一个日志中、"总可用大小"随着它的不断增长而变灰、甚至超过160 000 (该器件"只有"144 kB 的 RAM)。 我预计这会是测试原因或此区域的其他问题。

    实际问题是无法分配内存。 如前所述、有一个很好的解释：在某种情况下、"最大可用大小"低于23 KB。
    目前,我无法解释为什么"最大自由尺码"不断减少。 您建议内存未正确释放-这是可能的。 这可以解释存储器静态数据损坏的原因。

    此致、

  • 0
    TI__Guru**** 2943350 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好  

    感谢更新

    释放后,我们试图打印释放的变量的地址,它似乎只有 NULL 根据之前共享的日志。  

    因此我无法猜到问题所在。  

    1-在您提供的第一个日志中、"总可用大小"随着它的不断增长而变灰、甚至超过160 000 (该器件"只有"144 kB 的 RAM)。 我预计这会是测试原因或此区域的其他问题。 --->这只发生在我们的情况总是

  • 0
    TI__Guru**** 2943350 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好！

    有一种感觉。 这可能是由破坏堆的情况或某些分配/释放问题引起的。 我想、对这一点进行澄清应该是您在此优先考虑的事项、因为这将使调试变得非常困难。

    还有一些想法供您参考、请检查用1 KB 分配替换23 KB 分配是否有帮助。 然后逐渐增加分配的数目。

    对于之前的测试、请确保分配的内存被写入一点-否则我不知道工具链是否会优化代码并且摆脱 free/malloc。

    此致、

  • 0
    TI__Guru**** 2943350 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好  

    明白。 我正在尝试检查您的建议如何。

    在这之前、你能告诉我们堆栈和堆的配置位置。