Błąd PyLucene z IceTea/JDK/JRE

Question

Śledziłem instrukcje instalacyjne http://bendemott.blogspot.de/2013/11/installing-pylucene-4-451.html dla pylucenu przy użyciu najnowszego pylucene-4.9.0.0.

a kiedy próbował się lucene.initVM(), pojawia się następujący błąd:

alvas@ubi:~$ 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) 

a plik http://pastebin.com/6B8FyC4Z

Czy jest coś złego w mojej konfiguracji IceTea? lub mój JDK? lub JRE?

Jak powinienem rozwiązać problem?

Answer 1

Więc przyjrzałem się twojemu śladowi stosu, i nie sądzę, że problem był specyficznie pyLucene. W ślad stosu, widzisz ten błąd:

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

Jeśli spojrzeć na pierwszej części, SIGSEGV, czyli masz winy segmentacji gdzieś w systemie. SEGV_MAPERR jest specyficznym błędem, co oznacza, że ​​OpenJDK próbował odwzorować pamięć na obiekt i nie powiodło się. Mogło to być spowodowane brakiem pamięci, złym plikiem stronicowania/pamięci wirtualnej, złej przestrzeni adresowej lub nawet złej biblioteki. Dlaczego to działało na innej maszynie mogło być cokolwiek. Zrzuty rdzenia są bardzo użyteczne, więc jeśli możesz uruchomić tę aplikację, możesz podać coś, na co możesz się natrudzić. Czy to było w maszynie wirtualnej, czy na maszynie fizycznej? Widziałem losowe sigsegv w moich maszynach wirtualnych Ubuntu, jeśli nie mają wystarczającej ilości pamięci przydzielonej dla różnych zadań Java. Widziałem to szczególnie w moich hipernadzorcach ESXi i zauważyłem, że najbardziej było, gdy ESXi zaczął wymieniać pamięć. Udało mi się to rozwiązać, zwiększając pamięć, restartując maszynę wirtualną i upewniając się, że mój hiperwizor nie wymienia pamięci. Jeśli to pomoże, to daj mi znać. :)

Edycja: Zauważyłem również, że jeśli dostawca pamięci masowej miałby słabą wydajność, miałoby to wpływ na dane wymiany i uważam, że był to również wpływ z problemami sigsegv.