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

Question

开发环境：CentOS 4.7、KDevelopment3.1.1、GCC 3.4.6我运行了一个Java测试客户端，它使用JNI加载一个C+共享库。我的应用程序中有三个组件，Java客户端C+共享库，充当JNI包装器。(我称之为“包装库”)C+包含业务对象的共享库。(我称之为“商业图书馆”)当我运行客户端时，我经常会遇到一个错误，那就是，*** 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

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

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

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