发生错误后是否必须释放任何先前分配的内存？

Question

我正在为一个 uni 项目用 C 语言编写一个多线程服务器，我很难弄清楚如何以一种好的、可读的和标准的方式进行错误处理。

现在，如果程序成功终止，我会在程序结束时释放所有分配的内存。但是如果执行过程中出现致命错误（例如 malloc 返回NULL）怎么办？

例如，假设我有一个自定义数据类型mydata_t 和一个构造函数mydata_t *mydata_init()，我的程序的多个模块都在使用它。在网上看到一些代码后，我是这样写的：

mydata_t *mydata_init() {

    mydata_t *mydata = malloc(sizeof(mydata_t));
    if (!mydata) return NULL;

    mydata->field1 = malloc(sizeof(mydata2_t));
    if (!mydata->field1) return NULL;

    mydata->field2 = malloc(sizeof(mydata3_t));
    if (!mydata->field2) return NULL;

    /*
    Initialization of other fields
    */

    return mydata;

}

看起来确实很干净，但这是“标准”的做法吗？

特别是，如果其中一个 malloc 返回NULL 怎么办？是否有必要释放所有先前分配的内存？把代码改成这样合理吗？

mydata_t *mydata_init() {

    mydata_t *mydata = malloc(sizeof(mydata_t));
    if (!mydata) goto err_1;

    mydata->field1 = malloc(sizeof(mydata2_t));
    if (!mydata->field1) goto err_2;

    mydata->field2 = malloc(sizeof(mydata3_t));
    if (!mydata->field2) goto err_3;

    /*
    Initialization of other fields
    */

    return mydata;

/*
Other tags
*/

err_3:
    free(mydata->field1);
err_2:
    free(mydata);
err_1:
    return NULL;

}

Answer 1

现有的答案涵盖了各种 malloc/free 场景，所以我不会补充。

我想指出的是，如果您的 malloc 失败，那么程序几乎就结束了游戏，而且通常最好只使用exit() 而不是试图恢复这种情况。

即使您设法清理了部分分配的结构，该代码使用的其他代码和库也将无法分配内存，并且可能（并且经常会）以神秘的方式失败。

malloc() 通常只有在您运行在严格限制的环境中（例如嵌入式微控制器）或您像筛子一样泄漏内存时才会失败。

Answer 2

假设一个不平凡的操作系统，即一个带有“kill-9”的操作系统或一个在 GUI 上下文菜单上带有“结束进程”条目的任务管理器，请在开始一个冗长而昂贵的活动之前记住以下几点编写特定的用户代码以在发生致命错误时释放所有 malloc/whatever 内存：

1) 使用用户代码释放所有内存需要更多用户代码。必须在更改和/或新版本之后重复设计、编码测试和维护额外的代码。对于复杂的多线程应用程序，可能具有在线程之间共享和通信的对象池，甚至尝试使用用户代码关闭它都不是一件容易的事。

2) 在发生致命错误后使用用户代码释放所有内存会使事情变得更糟。如果错误是由损坏的堆管理器造成的，那么在尝试释放它时会引发更多错误。带有错误日志条目的应用程序“显示”在客户身上已经够糟糕了，屏幕上满是 AV 错误框和卡住的应用程序更糟糕。

3) 使用用户代码安全释放所有内存只能由线程完成，前提是所有其他线程都已停止，因此它们可能无法访问任何该内存。可靠地停止所有进程线程只能由操作系统在进程终止时完成。用户代码不能保证这样做——如果一个线程在库中执行冗长的操作时卡住了，你就不能可靠地停止它。例如，如果您尝试，它可能会使内存管理器保持锁定状态。仅仅解除阻塞在 I/O 操作上的线程就足够困难了，通常需要在本地网络堆栈上打开一个连接来强制 accept() 调用提前返回。

4) 操作系统的“终止进程”API 以及其中涉及的所有内容都经过了很多测试。它有效，并且随您的操作系统免费提供。您尝试停止线程和释放内存的用户代码永远不会积累那么多测试。

5) 试图停止线程和释放内存的用户代码是多余的——操作系统做同样的工作，只是更好、更快、更可靠。您正在尝试从操作系统将很快销毁和释放的子分配器中清理内存。

6) 许多操作系统和其他商业库已经让位于不可避免的情况，并接受他们不能安全地在关机时释放所有内存而不引起问题，尤其是对于多线程应用程序。图书馆作者不能可靠地做到这一点，你也不能。

当然，在运行期间以可控且合理的方式管理内存，根据需要释放 malloc 的内容，以免在进程的生命周期内泄漏内存。

但是，如果您遇到致命错误，可以尝试将详细信息写入日志文件或进行其他一些调试/记录操作（如果可以），然后调用您的操作系统“终止进程”API。

没有什么是你可以安全做的。

您的应用快要死了，让操作系统对其进行安乐死。

Answer 3

是否有必要释放所有先前分配的内存？

没有，但无泄漏（好）的代码可以。

你会发现关于如何做到这一点（释放东西）的各种意见，但最终目标是做到这一点，以某种方式。释放未使用的资源。

代码清晰。

注意：goto 形式是goto 的可接受用法。

---

我将提供另一种方法并尽可能使用mydata_uninit() 伴随函数。

mydata_t *mydata_uninit(mydata_t *mydata) {
  if (mydata) {
    free(mydate->field1); 
    mydate->field1 = NULL; // example discussed below **
    free(mydate->field2); 
    // free other resources and perform other clean up/accounting.
    free(mydate); 
  }
  return NULL;
}

我还将分配给取消引用指针的大小，而不是类型。

mydata_t *mydata_init(void) {
  mydata_t *mydata = calloc(1, sizeof *mydata);
  if (mydata == NULL) {
    return NULL;
  }   
  mydata->field1 = calloc(1, sizeof *(mydata->field1));
  mydata->field2 = calloc(1, sizeof *(mydata->field2));
  // Other 1st time assignments

  // If any failed
  if (mydata->field1 == NULL || mydata->field2 == NULL) {
    mydata = mydata_uninit(mydata);
  }

  return mydata;
}

** 将指针 struct 成员设置为 NULL (mydata->field1)，然后释放 struct 指针 (mydata) 我发现调试中的辅助工具是错误代码，它取消引用 NULL指针通常比释放的指针更快地出错。

Answer 4

一种可能的选择。

mydata_t *mydata_init()
{
    mydata_t *mydata = malloc(sizeof(mydata_t));
    if (mydata == NULL)
    {
        /* Handle error */
        return NULL;
    }

    mydata->field1 = malloc(sizeof(mydata2_t));
    mydata->field2 = malloc(sizeof(mydata3_t));
    ...

    if (mydata->field1 != NULL && 
        mydata->field2 != NULL &&
        ...)
    {
        /* success */
        /*
         * Initialize everything
         */
        return mydata;
    }

    free(mydata->field1);
    free(mydata->field2);
    ...
    free(mydata);
    return NULL;
}

请注意，在错误路径上调用 free() 之前，您无需检查 NULL。如this question的第一个答案所述

引用 ISO-IEC 9899 中的 C 标准 7.20.3.2/2：

如果 ptr 是空指针，则不执行任何操作。