Di fronte a un errore “*** glibc ha rilevato *** free (): dimensione successiva non valida (veloce)”

Si prega di consultare la domanda MSO Una lunga lista di possibili duplicati – allocazione di memoria C e limiti di overrunning per informazioni su domande strettamente correlate.


Ambiente di sviluppo: CentOS 4.7, Kdevelop 3.1.1, gcc 3.4.6

Eseguo un client di test Java che carica una libreria condivisa C ++ utilizzando JNI. Ci sono tre componenti nella mia applicazione,

  1. Client Java
  2. Libreria condivisa C ++ che funge da wrapper JNI. (Lo chiamerò “wrapperlibrary”)
  3. Libreria condivisa C ++ contenente oggetti business. (Lo chiamerò “businesslibrary”)

Quando eseguo il client, ho *** glibc detected *** free(): invalid next size (fast): 0x080eeef8 *** un errore molto frequente che è, *** glibc detected *** free(): invalid next size (fast): 0x080eeef8 *** . Questo errore si verifica per circa 10 – 11 volte e quindi l’applicazione viene eseguita.

Nel mio client Java, prima carico le librerie C ++ richieste in un ctor statico come segue,

 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 frase “business library loaded” viene stampata sulla console ma dopo di essa viene l’errore *** glibc...

Nelle impostazioni del progetto di wrapperlibrary, la libreria di business viene specificata come libreria dipendente. Quindi, anche se ometto la chiamata per caricare businesslibrary e basta scrivere,

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

quindi in primo luogo viene caricata la businesslibrary (vista attraverso la registrazione della creazione di variabili globali) e quindi viene caricata la wrapperlibrary. Il controllo ritorna al client java e l’istruzione “wrapper library loaded” viene stampata sulla console. Dopo questo c’è una chiamata al metodo nativo. Ma il controllo non raggiunge mai l’implementazione di questo metodo nativo. Anzi, prima arriva l’errore *** glibc... nuovo. Anche se inserisco una chiamata al metodo statico di un’altra class java prima della chiamata al metodo nativo come,

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

quindi l’output di Try.temp () non viene mai stampato.

Quali potrebbero essere le possibili ragioni del problema in entrambi questi approcci e come dovrei procedere?

Potrebbe essere che Java stesso sia collegato a un glibc diverso dalle tue librerie o che le librerie siano collegate in modo diverso / a diversi glibc.
Controllate anche se una delle librerie si collega a una versione di debug di glibc (che presenta il problema su Windows con la lib di runtime di C ++). Prova a colbind le tue librerie in modo statico con glibc, o per escludere le possibilità di colbind staticamente il wrapper e le librerie di business in un’unica libreria.

Ho incontrato questo errore criptico più volte.

In ogni caso è stato causato facendo riferimento a un membro dell’array esterno all’array. Il riferimento non ha causato un errore di segmentazione, poiché era ancora all’interno dei limiti di un altro array nel programma. Quando sono andato a liberare l’array, tuttavia, le cose erano incasinate abbastanza da gettare questo errore.

La correzione consisteva nel controllare attentamente che ogni array fosse correttamente assegnato e che i riferimenti ai membri dell’array non andassero mai fuori limite.