简体繁体 English

GNU C：如果我覆盖 malloc() free() 而不是 realloc() 会发生什么？

[英]GNU C: What will happen if i overwrite malloc() free() but not realloc()?

原文 2019-12-01 14:59:26 0 1 c/ malloc/ freertos

I am coding for an embedded system using ARM cross toolchain arm-none-ebi-gcc.我正在使用 ARM 交叉工具链 arm-none-ebi-gcc 为嵌入式系统编码。 Because the code is running freeRTOS which has its own heap memory management so I want to overwrite malloc(), free() and realloc() in the libc and wrap them simply to call the functions in freeRTOS.因为代码运行的是 freeRTOS，它有自己的堆内存管理，所以我想覆盖 libc 中的 malloc()、free() 和 realloc() 并将它们简单地包装起来以调用 freeRTOS 中的函数。 Only one problme, the freeRTOS does not have realloc(), that's strange, but my code definitely need it.只有一个问题，freeRTOS 没有 realloc()，这很奇怪，但我的代码绝对需要它。 So I want to understand, what will happen if I only overwrite malloc() and free() but still keep the realloc() the version as it be in the libc?所以我想了解，如果我只覆盖 malloc() 和 free() 但仍然保留 realloc() 的版本，因为它在 libc 中，会发生什么情况？ Also, I feel providing my own realloc() that just call malloc() with the new size and do the memcopy after the new memory block got allocated looks not safe enough to my mind, because the new size usually larger than the old size in my application, so when I do a memcopy() with a size larger than the actually allocated memory block will could create some pointer access error, it that possible?另外，我觉得提供我自己的 realloc() ，它只是用新的大小调用 malloc() 并在分配新的内存块后执行 memcopy 在我看来不够安全，因为新的大小通常大于旧的大小我的应用程序，所以当我执行大小大于实际分配的内存块的 memcopy() 时，可能会产生一些指针访问错误，这可能吗？

Thanks in advance.提前致谢。 -woody -木质的

1 个解决方案

Partially replacing the allocator (replacing some functions but not others) can't work.部分替换分配器（替换某些功能但不替换其他功能）不起作用。 At worst, you will get serious heap data structure corruption from one implementation interpreting another's data structures as its own.在最坏的情况下，您会因为一个实现将另一个的数据结构解释为自己的数据结构而导致严重的堆数据结构损坏。 It's possible to harden against this so that things just fail to link or fail to allocate (provide null pointer results) at runtime if this is done, and I did this in musl libc as described in these commits:有可能对此进行强化，以便在运行时无法链接或无法分配（提供空指针结果），如果这样做的话，我在这些提交中描述的 musl libc 中这样做了：

but I doubt many other implementations take the same precautions.但我怀疑许多其他实施是否采取了相同的预防措施。 And they won't help what you want actually work;而且它们不会帮助您实际工作； they'd just prevent catastrophic results.他们只是防止灾难性的结果。

If you really need realloc , you're going to have to make a working one for the implementation you're adopting.如果你真的需要realloc ，你将不得不为你正在采用的实现做一个工作。 The easiest way to do that is make it just malloc , memcpy , and free , but indeed you need a way to determine the length argument to pass to memcpy .最简单的方法是只使用malloc 、 memcpy和free ，但实际上您需要一种方法来确定要传递给memcpy的长度参数。 If you just pass the new length, it might be safe on a microcontroller without MMU, as long as your lengths aren't so large they risk running over into an MMIO range or something.如果您只是通过了新长度，那么在没有 MMU 的微控制器上它可能是安全的，只要您的长度不是太大，它们就有可能超出 MMIO 范围或其他范围。 But the right thing to do is read the malloc implementation enough to understand where it's stored the allocated size, and write your own code to extract that.但正确的做法是充分阅读malloc实现以了解它存储分配大小的位置，然后编写自己的代码来提取它。 At that point you can write a correct/valid realloc using memcpy .那时您可以使用memcpy编写正确/有效的realloc 。