# libreoffice friert ein beim Start [gelöst]

## Randy Andy

Hi Gentooler,

habe schon länger an meinem Atom-Netbook das Problem, dass mir Libreoffice beim Start einfriert und es beim Splash-Screen hängen bleibt.

Dabei ist es ganz egal, welche der Office Komponenten ich starte.

Zuvor hatte ich schon mit einigen der 5er Releases erfolgreich gearbeitet, aber nach irgendeinem world update fingen die Probleme damit an.

Aktuell verwende ich libreoffice-5.1.2.2. Bin Gestern noch auf eine Bug-Report https://bugs.gentoo.org/show_bug.cgi?id=560172 gestoßen und hatte die Hoffnung, dass es vielleicht am einkompilierten gtk und gtk3 Use-Flag liegen könnte und habe es daher noch einmal ohne gtk3 Flag kompiliert, hat aber nichts verbessert.

Starte ich zum Beispiel den writer aus einem x-terminal erhalte ich folgendes:

```
libreoffice --writer

javaldx: Could not find a Java Runtime Environment!

Warning: failed to read path from javaldx

```

Allerdings auch auf den anderen PCs auf denen es trotzdem stabil läuft.

Libreoffice ist zwar ohne debug symbols kompiliert, aber vielleicht nutzt Euch ja die Ausgabe von strace beim Start des writers ja trotzdem etwas, um mir helfen zu können. Ihr findet sie hier:

https://bpaste.net/show/76711a4e8736

Zusätzlich findet ihr noch die Ausgabe von

```
lsof|grep '^soffice'|grep ' /usr/lib'|sed -e 's:^.* /usr/::g'|sort
```

hier: https://bpaste.net/show/ff6f4eec6d40

Was hab ich noch versucht, weitere Hinweise:

In meinem ~user Verzeichnis das .config/libreoffice/ Verzeichnis gelöscht - nix.

Bin schon immer komplett auf ~x86 Arch, hatte damit aber noch nie Probleme.

Es wurde mit Gcc-5.3 kompiliert.

Das Problem besteht mindestens seit glibc-2.22-r3,r4, 2.23.-r1

Wie gehe ich systematisch am besten an die Fehlersuche?

Danke fürs Mitdenken,

Andy.

----------

## Randy Andy

Weiter geht's,

denn ich hatte dank Btrfs zwischenzeitlich versucht, von ein paar älteren Snapshots zu booten, um zu sehen mit welcher Version von LO das zum letzten mal noch funktioniert hatte.

Also mit einem Snapshot von 2016-02-17 läuft es noch, hierbei kamen folgende Versionen zum Einsatz:

libreoffice-5.0.4.2 kompiliert mit folgenden USE-Flags: branding, cups, dbus, gstreamer, gtk, gtk3, 

glibc-2.22-r1

gcc-5.3

liborcus-07

Der nächste Snapshot, ab dem LO schon nicht mehr lief, stammte von 2016-03-01 mit folgenden Paketen:

libreoffice-5.1.0.3 kompiliert mit den gleichen Flags wie oben.

glibc-2.22.-r2

gcc-5.3

Hab dann noch von der letzten funktionierenden Version 5.0.4.2 nachträglich ein bin-package erstellt, das in den aktuellen Snapshot kopiert und dort versucht es zu installieren. Da gibt's aber zuviel Mecker wegen zu sehr auseinander driftender Versionen die er dann auch noch alle als bin haben wollte oder masked packages Mecker weil diese Versionen in der Zwischenzeit ausm tree geflogen sind etc. etc.

Lange Rede kurzer Sinn, ich versuch nun auf der Kiste erst mal die letzte stable version zu kompilieren, (5.0.5.2) um mal zu sehen ob diese wenigstens wieder läuft.

Und nein, ich möchte nicht die -bin Version installieren, nur weil das schneller geht, auch wenn das auf so einem schwachen Atom-Netbook ganz schön dauern kann.

Hoffe aber, dass es dank distcc etwas schneller fluppt.

Gruß, Andy

----------

## Randy Andy

Ich habe fertig! (compiliert)

Es werkelt nun also libreoffice-5.0.5.2 (aka stable) die aber leider genauso beim Start einfriert.  :Sad: 

Damit gehe ich also wieder zurück auf Los, ziehe keine 2000€ (4000 DM) ein und hoffe ihr habt dann noch'n Tipp für mich...

Gruß, Andy.

----------

## Klaus Meier

Ich tippe einfach mal so... Eventuell liegt es an dri3. Das ist bei mir seit einiger Zeit per default aktiviert. Und führt dazu, dass manche Anwendungen einfrieren oder abstürzen.

----------

## Randy Andy

Danke für den Tipp, Klaus.

Es lag doch tatsächlich am standardmäßig bei mesa gesetzten dri3 Flag, obwohl das in meinen globalen oder lokalen USE-Flag-Settings nicht gesetzt war.

Auch im xf86-video-intel war es einkompiliert, mit dem mein Netbook ausgestattet ist. Intel ist AFAIK in Sachen dri3 Vorreiter.

Auf meinen anderen PCs dagegen, mit Nvidia-Karten machte sich das noch nicht negativ bemerkbar, vermutlich weil es dort noch gar nicht zum tragen kommt.

Habe es jedenfalls jetzt global deaktiviert, rekompiliert und nu klappts! 

Besten Gruß, Andy.

----------

## Klaus Meier

Bei mesa ist das dri3-Flag schon seit langem per default gesetzt. Bis es dann irgendein Depp auch beim intel-Treiber per default aktiviert hat. Und seit dem gibt es Ärger ohne Ende. Es kommen aktuell ja auch drei Updates für diesen Treiber pro Woche, aber geändert hat sich noch nichts. Ich kann es aktuell nur bei Intel testen.

Auf alle Fälle: Manuell deaktivieren, sonst gibt es Ärger ohne Ende.

----------

## Randy Andy

Was zu beweisen war! (dank Klaus).

Frage @all:

Wie hätte man anhand welcher Informationen (strace, dmesg, etc.) die Fehlerursache identifizieren können, um letztlich auf dri3 oder wenigstens auf ein Grafik-Treiber-Problem schließen zu können?

Sprich wie hätte man das korrekt debuggen können, damit ich beim nächsten mal nicht wieder Rätselraten spielen muss?

----------

