面临错误“检测到 *** glibc *** free(): invalid next size (fast)”

Posted 2023-02-24

【中文标题】面临错误“检测到 *** glibc *** free(): invalid next size (fast)”

【英文标题】：Facing an error "*** glibc detected *** free(): invalid next size (fast)"

【发布时间】：2011-01-19 23:53:35

【问题描述】：

请参阅 MSO 问题A long list of possible duplicates — C memory allocation and overrunning bounds，了解密切相关的问题。

---

开发环境：CentOS 4.7、Kdevelop 3.1.1、gcc 3.4.6

我运行一个 Java 测试客户端，它使用 JNI 加载一个 C++ 共享库。我的应用程序中有三个组件，

Java 客户端 用作 JNI 包装器的 C++ 共享库。 （我将其称为“包装库”） 包含业务对象的 C++ 共享库。 （我称之为“商业图书馆”）

当我运行客户端时，我经常遇到一个错误，即*** glibc detected *** free(): invalid next size (fast): 0x080eeef8 ***。此错误出现大约 10 到 11 次，然后应用程序运行。

在我的 Java 客户端中，我首先将所需的 C++ 库加载到静态 ctor 中，如下所示，

static

System.Load("/root/Desktop/libs/businesslibrary");
System.out.println("business library loaded");
System.Load("/root/Desktop/libs/wrapperlibrary");
System.out.println("wrapper library loaded");

“业务库已加载”语句打印在控制台上，但随后出现错误 *** glibc...。

在wrapperlibrary的项目设置中，businesslibrary被指定为依赖库。所以，即使我省略了加载 businesslibrary 的调用而只写，

static

System.Load("/root/Desktop/libs/wrapperlibrary");
System.out.println("wrapper library loaded");

然后首先加载businesslibrary（通过全局变量创建日志查看），然后加载wrapperlibrary。控件返回 java 客户端，并在控制台上打印语句“已加载包装库”。在此之后有一个电话 到本地方法。但是控件永远不会到达这个本机方法的实现。而在此之前，错误*** glibc... 再次出现。此外，如果我在本地方法调用之前插入对另一个 java 类的静态方法的调用，例如，

static

 System.Load("/root/Desktop/libs/wrapperlibrary");
 System.out.println("wrapper library loaded");
 System.out.println(Try.temp()); //where temp is a static method of Try class which returns a string.

 native method call;

 --
 --

然后 Try.temp() 的输出永远不会被打印出来。

这两种方法中出现问题的可能原因是什么？我应该如何处理？

【问题讨论】：

您的共享库似乎有问题。

@Laurynas - Valgrind 向我展示了两个错误，但仅提到即使在调试版本中也没有解决实际代码。所以，不知道下一步该怎么做。由于空间不足，粘贴了一段输出。 ==23002== 跳转到下一行说明的无效地址 ==23002== 在 0x246: ??? ==23002== 地址 0x246 未堆栈、malloc 或（最近）释放 ==23002== ==23002== 进程以信号 11（SIGSEGV）的默认操作终止 ==23002== 错误地址 0x246 ==23002== 0x246 处映射区域的权限：???

@Adil - 共享库在与 C++ 可执行文件一起使用时工作正常，但在通过 Java 加载时会出现问题。我已经看到问题显然出现在共享库的加载阶段。

@HS Address 0x246 作为跳转目标看起来肯定是错误的。是否还有其他行不是“在 0xADDRESS”而是“通过 0xADDRESS”？

【参考方案1】：

可能是 Java 本身链接到与您的库不同的 glibc，或者这些库链接到不同/不同的 glibcs​​。 还要检查其中一个库是否链接到 glibc 的调试版本（在带有 C++ 运行时库的 Windows 上解决该问题）。 尝试将您的库静态链接到 glibc，或者为了排除将您的包装器和业务库静态链接到一个库的可能性。

【讨论】：

解决方案与您的建议有些相似 - 它与链接有关。业务库有自己的覆盖宽字符 API 的实现，因为它使用 2 字节 Unicode。预计会链接到这些 api，而是动态链接到预计大小为 4 的系统 api。我已经更改了被覆盖的 api 的名称来纠正这个问题。现在包装器和业务库都与被覆盖的 api 链接。谢谢。

@HS：如果您自己解决问题，您可以将解决方案作为答案发布并接受，以便其他人找到。

【参考方案2】：

我已经多次遇到这个神秘的错误。

在每种情况下，它都是由引用数组外部的数组成员引起的。该引用没有导致分段错误，因为它仍在程序中另一个数组的范围内。然而，当我去释放数组时，事情变得一团糟，以至于引发了这个错误。

解决方法是非常仔细地检查每个数组是否正确分配，并且对数组成员的引用永远不会超出范围。