course PyCharm sur ArchLinux

Question

J'utilise PyCharm-professionnel sur linux arc, mais depuis hier, il ne fonctionne pas correctement, voici l'erreur quand il en cours d'exécution dans temrinal:

[kahrabian@Kian-Arch ~]$ pycharm 
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=350m; support was removed in 8.0 
Picked up _JAVA_OPTIONS: -Dawt.useSystemAAFontSettings=lcd 
# 
# A fatal error has been detected by the Java Runtime Environment: 
# 
# SIGSEGV (0xb) at pc=0x00007f26f93b5be0, pid=1999, tid=139805401143040 
# 
# JRE version: Java(TM) SE Runtime Environment (8.0_60-b27) (build 1.8.0_60-b27) 
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.60-b23 mixed mode linux-amd64 compressed oops) 
# Problematic frame: 
# C 0x00007f26f93b5be0 
# 
# 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/kahrabian/java_error_in_PYCHARM_1999.log 
# 
# If you would like to submit a bug report, please visit: 
# http://bugreport.java.com/bugreport/crash.jsp 
# 
/opt/pycharm-professional/bin/pycharm.sh: line 187: 1999 Aborted     (core dumped) LD_LIBRARY_PATH="$IDE_BIN_HOME:$LD_LIBRARY_PATH" "$JDK/bin/java" $AGENT "-Xbootclasspath/a:$IDE_HOME/lib/boot.jar" -classpath "$CLASSPATH" $VM_OPTIONS "-Djb.vmOptionsFile=$VM_OPTIONS_FILES_USED" "-XX:ErrorFile=$HOME/java_error_in_PYCHARM_%p.log" -Djb.restart.code=88 -Didea.paths.selector=PyCharm40 $IDE_PROPERTIES_PROPERTY $IDE_JVM_ARGS $REQUIRED_JVM_ARGS $MAIN_CLASS_NAME "$@" 

et voici le fichier journal généré après avoir essayé de lancer pycharm: http://paste.ubuntu.com/12775734/ comme je ne peux pas comprendre le problème et son origine, j'ai besoin d'aide pour résoudre ce problème.

Answer 1

Malheureusement, il s'agit d'une incompatibilité connue avec la jib actuelle et Oracle JVM.

Voir ici: https://youtrack.jetbrains.com/issue/IDEA-146207 Et ici: https://bugzilla.gnome.org/show_bug.cgi?id=755609

Il y a quelques solutions de contournement que vous pouvez utiliser pour le moment (trouvé d'ici: https://bugs.archlinux.org/task/46619)

1. Prepend la commande avec PRELOAD=/lib/libglib-2.0.so (par exemple)
2. Installez cette lettre d'information corrigée à partir du fil de discussion arch (je serais fatigué d'utiliser cette solution sans d'abord vérifier la sécurité de ce paquet): http://pkgbuild.com/~heftig/glib2-2.46.0-2-x86_64.pkg.tar.xz
3. Rétrograder GLib-2 pour l'instant (ne fonctionne que si l'ancien paquet est toujours en cache). La commande pour faire ceci ressemblera à ceci: pacman -U /var/cache/pacman/pkg/glib2-2.44.1-1-x86_64.pkg.tar.xz. Vous pouvez également rétrograder le package à l'aide d'autres outils, tels que la rétrogradation à partir de AUR, la seule exécution downgrade glib2

Espérons que ce bogue sera bientôt écrasé.

Answer 2

Pour toute personne exécutant autre dans cette erreur et ne veulent pas rétrograder glib, la commande de l'étape 1 solution doit être modifiée:

# x64 
LD_PRELOAD=/lib64/libglib-2.0.so pycharm 
# x86 
LD_PRELOAD=/lib/libglib-2.0.so pycharm 

Answer 3

Il y a un paquet pré-construit dans ce repo:

[archlinuxcn] 
SigLevel = Optional TrustAll 
Server = http://repo.archlinuxcn.org/$arch 

Answer 4

pour construire sur la réponse donnée par @ 8bitAce:

Vous ne fait pas besoin d'installer la version glib2 plus afin de l'utiliser pour exécuter PyCharm. Il suffit d'extraire l'ancien paquet glib2 quelque part dans votre répertoire personnel:

mkdir -p $HOME/oldlibs/pycharm 
tar Jxf /var/cache/pacman/pkg/glib2-2.44.1-1-x86_64.pkg.tar.xz -C $HOME/oldlibs/pycharm 

Puis commencer à PyCharm:

LD_PRELOAD=$HOME/oldlibs/pycharm/usr/lib/libglib-2.0.so pycharm 

De cette façon, le reste de vos programmes (qui peut dépendre de la version plus récente du glib2) ne sont pas forcé à utiliser une ancienne version de glib2, et courir le risque d'autres problèmes.

Answer 5

J'ai eu le même problème. J'utilisais OpenJDK JRE 9, et cela semble avoir été la source du problème. J'ai ensuite installé le JRE 8 d'Oracle et tout va bien. Peut-être qu'avec OpenJDK JRE 8 ça marchera aussi.