Redhat AS 4 seg ошибка вызова magic_buffer с использованием Java 1.6 - PullRequest
0 голосов
/ 21 января 2010

У меня есть класс Java, который вызывает класс C ++ через класс JNI C ++ для доступа к функциональности команды 'file', предоставляемой libmagic.so.

  • Класс C ++ компилируется и нормально работает как main () C ++

- Отлично работает на RHEL 5 под управлением Java 1.5 и 1.6;

- отлично работает на RHEL 4 под управлением Java 1.5

- сбрасывает ошибку сегмента 26234 на RHEL 4 с Java 1.6

Ошибка сегмента:

  1. Происходит при вызове char * retptr = magic_buffer (cookie, bigbuf, 1000); Нет вины, когда char * retptr = «хорошая безопасная строка символов»; замещен Вот почему я пришел к выводу, что ошибка seg возникает при этом вызове.

  2. Я использую альтернативный вызов char * retptr = magic_file (cookie, ”/ usr / include / magic.h”); для устранения проблем с буфером, так как этот вызов возвращает то же сообщение о типе файла, для которого требуется только полный путь к файлу, а не буфер с полным содержимым файла. Это также вызывает ошибку seg на тестовой виртуальной машине RHEL4 / java 1.6. Таким образом, я прихожу к выводу, что в моем коде проблема заключается не в плохих указателях или переполнении буферов.

  3. magic_buffer - это вызов libmagic.so. В коде ранее были сделаны другие успешные вызовы этой библиотеки. Этот вызов, однако, включает в себя базу данных lib magic /usr/share/file/magic.

  4. Компиляция C ++ как исполняемого файла и запуск его на проблемной машине работает просто отлично.

Вот некоторые выводы:

A. Из-за # 4

есть участие JNI

B. Из-за # 1 / # 2 я не верю, что это проблема реализации JNI.

C. Из-за # 1, # 2 и # 4 я не верю, что это проблема реализации c ++.

Есть предложения или комментарии? (изначально работал на VMWare, сейчас тестируется без участия виртуальной машины)

1 Ответ

0 голосов
/ 21 января 2010

Мое первое предложение - попытаться найти альтернативу чистой Java. Эта страница содержит список альтернатив. Apache Tika и JMimeMagic выглядят многообещающе.

Мое второе предложение - использовать Process для запуска команды file в отдельном процессе и извлекать необходимую информацию из стандартного вывода команды. Это может привести к (ahem) проблемам с производительностью, если вам нужно делать это сотни раз в секунду, но для случайного использования это должно подойти.

...