为何curl_easy_perform在Unity测试中触发SEGFAULT，常规程序却正常？

核心矛盾很明确：相同调用逻辑下，Unity测试触发段错误，普通程序正常运行；注释掉request_set_headers里设置CURLOPT_HTTPHEADER的代码就恢复，说明问题肯定出在curl的HTTP头部链表管理，或者测试框架的内存环境差异上。

1. 先查curl_slist的生命周期问题 #

这是curl使用中最常见的坑：

• 你在request_set_headers里创建的curl_slist链表，有没有在request_fetch执行完成后调用curl_slist_free_all释放？
  • 普通程序跑完就退出，系统会回收内存，哪怕没主动释放也不会暴露问题；但Unity测试会复用进程空间，上一次测试残留的野指针会在下次测试触发段错误
• 有没有重复设置CURLOPT_HTTPHEADER但没先释放旧链表？比如：

  // 错误示例：直接覆盖旧链表，导致内存泄漏+野指针
  curl_easy_setopt(curl, CURLOPT_HTTPHEADER, new_headers);
  // 正确做法：先释放旧链表，再设置新的
  curl_slist_free_all(prev_headers);
  prev_headers = new_headers;
  curl_easy_setopt(curl, CURLOPT_HTTPHEADER, prev_headers);
  

2. 检查测试框架的内存初始化差异 #

Unity测试框架会对内存做特殊处理（比如清零或者填充0xdeadbeef这类标记值），而普通程序的堆内存是系统默认的随机值，这会把隐藏的内存问题放大：

• 比如构建curl_slist时，有没有把链表头初始化为NULL？

  // 错误示例：链表头未初始化，值为随机垃圾
  curl_slist *headers;
  headers = curl_slist_append(headers, "Content-Type: application/json");
  // 正确做法：必须初始化为NULL
  curl_slist *headers = NULL;
  headers = curl_slist_append(headers, "Content-Type: application/json");
  

  普通程序里随机值可能刚好是NULL，不会出错；但Unity初始化的内存可能是无效地址，直接触发段错误。

3. 测试用例的状态污染问题 #

如果多个测试用例共享同一个curl句柄或者全局变量，前一个测试的残留数据会搞崩后面的测试：

• 检查每个测试用例的SETUP()和TEARDOWN()，是不是每次都重新创建curl句柄，测试结束后调用curl_easy_cleanup，同时释放headers链表？
• 别图省事用全局的curl实例，测试环境下全局变量的状态残留是重灾区。

4. 深挖Valgrind的日志细节 #

别只看“无效内存访问”的结论，重点看访问的地址上下文：

• 如果地址指向curl_slist的节点，说明链表要么被提前释放了，要么根本没正确创建
• 用valgrind --leak-check=full --show-leak-kinds=all ./your_test_binary重新运行，看有没有curl_slist的内存泄漏或者重复释放的记录，这些都是关键线索

5. 回调函数的隐性问题 #

虽然你说WriteMemoryCallback是取自官方文档，但还是要核对：

• 里面的内存分配逻辑有没有越界？比如计算新内存大小的时候有没有算错字节数？
• 测试场景下的响应数据是不是触发了边界情况（比如空响应、超大响应）？

快速验证步骤 #

1. 在request_set_headers里，设置CURLOPT_HTTPHEADER前，不管有没有旧链表，先调用curl_slist_free_all释放一次（保险起见）
2. 在每个测试用例的收尾阶段，强制释放headers链表和curl句柄，不要依赖全局清理
3. 打印curl_slist的节点地址和内容，对比测试环境和普通程序的输出，看有没有异常

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