linux - Frente a un error "*** glibc detected*** free(): invalid next size(fast)"

jni centos

Question

Consulte la pregunta de MSO. Una larga lista de posibles duplicados: asignación de memoria en C y límites de desbordamiento para obtener información sobre preguntas estrechamente relacionadas.

Entorno de desarrollo: CentOS 4.7, Kdevelop 3.1.1, gcc 3.4.6

Ejecutar un cliente de prueba de Java que carga una biblioteca compartida de C ++ utilizando JNI. Hay tres componentes en mi aplicación,

1. Cliente Java
2. Biblioteca compartida C ++ que actúa como un contenedor JNI. (Lo llamaré "wrapperlibrary")
3. Biblioteca compartida de C ++ que contiene objetos comerciales. (Lo llamaré "businesslibrary")

Cuando ejecuto el cliente me encuentro con un error muy frecuente que es, *** glibc detected *** free(): invalid next size (fast): 0x080eeef8 *** . Este error viene por alrededor de 10 a 11 veces y luego se ejecuta la aplicación.

En mi cliente Java, primero cargo las bibliotecas requeridas de C ++ en un ctor estático de la siguiente manera:

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");
}

La instrucción "biblioteca comercial cargada" se imprime en la consola, pero luego aparece el error *** glibc...

En la configuración del proyecto de wrapperlibrary, businesslibrary se especifica como una biblioteca dependiente. Entonces, incluso si omito la llamada para cargar businesslibrary y solo escribo,

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

luego, primero se carga la biblioteca comercial (vista a través del registro global de creación de variables) y luego se carga el wrapperlibrary. El control vuelve al cliente Java y la instrucción "contenedor de la biblioteca cargada" se imprime en la consola. Después de esto hay una llamada al método nativo. Pero el control nunca llega a la implementación de este método nativo. Antes, el error *** glibc... viene de nuevo. También si inserto una llamada al método estático de otra clase java antes de la llamada al método nativo como,

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;
--
--
}

entonces la salida de Try.temp () nunca se imprime.

¿Cuáles podrían ser las posibles razones del problema en ambos enfoques y cómo debo proceder?

Answer 1

Podría ser que Java esté vinculada a un glibc diferente de sus bibliotecas o que las bibliotecas estén vinculadas de forma diferente / a glibcs ​​diferentes.
También verifique si una de las bibliotecas está enlazando con una versión de depuración del glibc (o ese problema en Windows con la lib del tiempo de ejecución de C ++). Intente vincular estáticamente sus bibliotecas con el glibc, o con el fin de excluir las posibilidades que enlazan su contenedor y sus bibliotecas de negocios de forma estática en una sola biblioteca.

Answer 2

He encontrado este error críptico varias veces.

En cada caso, fue causado al hacer referencia a un miembro de la matriz que estaba fuera de la matriz. La referencia no causó un error de segmentación, ya que aún estaba dentro de los límites de otra matriz en el programa. Sin embargo, cuando fui a liberar el arreglo, las cosas se complicaron lo suficiente como para arrojar este error.

La solución fue verificar muy cuidadosamente que cada matriz estuviera correctamente asignada, y que las referencias a los miembros de la matriz nunca salieran de los límites.