Вопрос:

Обнаружена ошибка «*** glibc обнаружено *** free (): неверный следующий размер (быстрый)»

linux java-native-interface centos

14582 просмотра

2 ответа

194 Репутация автора

См. Вопрос MSO . Длинный список возможных дубликатов - распределение памяти C и превышение границ для получения информации о тесно связанных вопросах.


Среда разработки: CentOS 4.7, Kdevelop 3.1.1, gcc 3.4.6

Я запускаю тестовый клиент Java, который загружает разделяемую библиотеку C ++ с использованием JNI. В моем приложении три компонента:

  1. Java-клиент
  2. C ++ разделяемая библиотека, которая действует как оболочка JNI. (Я назову это "библиотека-обертка")
  3. Совместная библиотека C ++, содержащая бизнес-объекты. (Я назову это "businesslibrary")

Когда я запускаю клиент сталкивается ошибка очень часто что, *** 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....

В настройках проекта библиотеки-оболочки бизнес-библиотека указывается как зависимая библиотека. Так что, даже если я опущу вызов, чтобы загрузить businesslibrary и просто написать,

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 () никогда не печатается.

Каковы могут быть возможные причины проблемы в обоих этих подходах и как мне действовать дальше?

Автор: HS. Источник Размещён: 23.02.2010 09:35

Ответы (2)


4 плюса

1233 Репутация автора

Решение

Возможно, что сама Java связана с другим glibc, чем ваши библиотеки, или библиотеки связаны по-разному / с разными glibcs.
Также проверьте, не связывается ли одна из библиотек с отладочной версией glibc (эта проблема возникает в Windows с библиотекой времени выполнения C ++). Попробуйте статически связать ваши библиотеки с glibc или исключить возможности статического связывания вашей оболочки и бизнес-библиотек в одну библиотеку.

Автор: Dominik Fretz Размещён: 06.04.2010 11:46

1 плюс

48 Репутация автора

Я сталкивался с этой загадочной ошибкой несколько раз.

В каждом случае это было вызвано ссылкой на элемент массива, который находился вне массива. Ссылка не вызвала ошибку сегментации, так как находилась в пределах другого массива в программе. Однако когда я отправился освобождать массив, все было достаточно запутано, чтобы вызвать эту ошибку.

Исправление было в том, чтобы очень тщательно проверить, правильно ли размещен каждый массив, и чтобы ссылки на элементы массива никогда не выходили за пределы.

Автор: Boffin Размещён: 03.06.2016 05:03
Вопросы из категории :
32x32