面对错误“* glibc检测到* free()：无效的下一个大小(fast)”

Question

有关密切相关问题的信息，请参见MSO问题A long list of possible duplicates — C memory allocation and overrunning bounds。

开发环境: CentOS 4.7、KDevelopment3.1.1、gcc 3.4.6

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

2. 客户端
3. C++共享库，充当JNI包装器。(我将称之为包含业务对象的"wrapperlibrary")
4. C++共享库。(我称它为"businesslibrary")

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

在我的Java中，我首先在静态ctor中加载所需的C++库，如下所示：

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...。

在包装库的项目设置中，业务库指定为依赖库。所以，即使我省略了加载业务库的调用，只需编写，

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

然后，首先加载业务库(通过全局变量创建日志来查看)，然后加载包装库。该控件返回到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()的输出就永远不会被打印出来。

在这两种方法中，造成这一问题的可能原因是什么，我应该如何处理？

Answer 1

这可能是因为Java本身是针对与库不同的glibc链接的，或者库与不同的glibcs有不同的链接。

还请检查其中一个库是否与glibc的调试版本链接( C++运行时库在windows上存在问题)。尝试使用glibc静态地链接库，或者为了排除将包装器和业务库静态链接到一个库中的可能性。

Answer 2

我曾多次遇到这个隐秘的错误。

在每种情况下，它都是通过引用数组之外的数组成员引起的。引用没有导致分段错误，因为它仍然在程序中的另一个数组的范围内。然而，当我去释放数组时，事情已经混乱到足以抛出这个错误了。

修复方法是非常仔细地检查每个数组是否被正确分配，并且对数组成员的引用从未超出范围。