Ошибка PyLucene с IceTea/JDK/JRE - программирование

Я выполнил инструкцию по установке http://bendemott.blogspot.de/2013/11/installing-pylucene-4-451.html для пилюцена с использованием последней pylucene-4.9.0.0.

И когда я попытался выполнить lucene.initVM(), я получаю следующую ошибку:

[email protected]:~$ python
Python 2.7.6 (default, Mar 22 2014, 22:59:56) 
[GCC 4.8.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import lucene
>>> lucene.initVM()
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007ffba22808b8, pid=5189, tid=140718811092800
#
# JRE version: OpenJDK Runtime Environment (7.0_65-b32) (build 1.7.0_65-b32)
# Java VM: OpenJDK 64-Bit Server VM (24.65-b04 mixed mode linux-amd64 compressed oops)
# Derivative: IcedTea 2.5.3
# Distribution: Ubuntu 14.04 LTS, package 7u71-2.5.3-0ubuntu0.14.04.1
# Problematic frame:
# V  [libjvm.so+0x6088b8]  jni_RegisterNatives+0x58
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /home/alvas/hs_err_pid5189.log
#
# If you would like to submit a bug report, please include
# instructions on how to reproduce the bug and visit:
#   http://icedtea.classpath.org/bugzilla
#
Aborted (core dumped)

И файл http://pastebin.com/6B8FyC4Z

Что-то не так с моей конфигурацией IceTea? или мой JDK? или JRE?

Как решить проблему?

Ответ 1

Итак, я взглянул на вашу трассировку стека, и я не думаю, что проблема была конкретно pyLucene. В трассировке стека вы видите эту ошибку:

siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), si_addr=0x0000000000000000

Если вы посмотрите на первую часть, SIGSEGV, это означает, что у вас есть ошибка сегментации где-то в вашей системе. SEGV_MAPERR - это конкретная ошибка, а это означает, что OpenJDK пытается сопоставить память с объектом и не удалось. Это может быть вызвано нехваткой памяти, плохим файлом подкачки/виртуальной памятью, плохим адресным пространством или даже плохой библиотекой. Почему он работал на другой машине, может быть что угодно. Дампы ядра действительно полезны, поэтому, если вы можете запустить

ulimit -c unlimited

который поможет вам кое-что посмотреть. Это было в виртуальной машине или на физической машине? Я видел случайные sigsegv в своих Ubuntu VM, если у них недостаточно памяти для различных задач Java. Я видел это на своих гипервизорах ESXi специально, и я заметил, что это было самое главное, когда ESXi начал выполнять обмен памяти. Я смог решить это, увеличив память, перезагрузив виртуальную машину и убедившись, что мой гипервизор не меняет память. Дайте мне знать, если это поможет.:)

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