C语言‘attempt to free a non-heap object’编译警告的原因

警告直接成因 #

你代码触发该警告的核心是：传入record_cleanup执行清理的对象本身是栈上分配的局部变量，不属于堆内存范畴，却最终被传入free作为待释放指针。
main函数中定义的struct record record是普通局部变量，没有通过malloc系列接口申请堆空间，它的地址完全不满足free的入参要求，因此直接触发了编译期的错误提示。

背后的底层原理 #

• C语言对不同内存区域的管理机制存在本质差异：
  • 栈内存：普通局部变量的存储空间由运行时的栈帧机制自动管理，函数调用时自动为变量分配栈上空间，函数执行完毕弹出栈帧时，这块内存会被运行时自动回收，整个过程不需要、也不允许手动调用内存释放函数介入。
  • 堆内存：只有通过malloc、calloc、realloc这类标准库接口申请的内存才属于堆区，这块内存的生命周期完全由开发者手动控制，必须显式调用free才能将内存归还给堆管理器，否则会产生内存泄漏。
• free函数本身有严格的入参约束：它的内部实现依赖每个堆内存块前置的元数据（比如块大小、堆链表节点指针等信息）定位待释放的内存区域。一旦传入的指针不是合法的堆分配地址，free会错误地把栈内存上的随机值当成堆元数据解析，轻则直接触发程序崩溃，重则破坏堆的链表结构造成不可预期的运行时问题，这类行为属于C标准定义的未定义行为。

警告的触发逻辑 #

现代编译器（GCC、Clang等）内置了指针来源追踪的静态分析能力，它可以逐层跟踪指针的传递路径：识别到&record是栈局部变量的地址，沿着函数传参路径追踪到这个地址最终被传入free的调用点，不需要等程序运行就能直接匹配到“释放非堆对象”的错误模式，提前抛出这个警告。

常见设计误区 #

这类问题通常是编写通用清理函数时的设计边界模糊导致的：

• 如果约定record_cleanup的职责是释放整个record对象本身，那调用方必须保证传入的指针是堆分配的，在main中传栈对象的地址就属于接口误用。
• 如果需要同时支持栈上、堆上的record对象做内部资源清理，需要把“释放record内部持有的堆资源”和“释放record对象本身的内存”两个逻辑拆分开，避免对栈对象的地址执行free操作。

内容的提问来源于stack exchange，提问作者user14430844