LO Writer 2.4.2: Absaetze loeschen fuehrt zu Absturz

Hallo,
ich habe hier einen Brief, der LibreOffice Writer beim Speichern
abstürzen lässt, wenn man (leere) Absätze löscht. Es scheint nicht egal
zu sein, welche Absätze gelöscht werden, denn bei einigen ging es gut.
Ich hatte, um der Sache auf die Spur zu kommen, Zeichen für Zeichen
gelöscht und bei jedem einzelnen gelöschten Zeichen gespeichert. Jetzt
sind noch etwa fünf leere Absätze im Dokument enthalten, die nur Platz
kosten, die ich aber nicht löschen kann, ohne dass LibreOffice beim
Speichern abstürzt.

Gibt es eine erfolgversprechende Methode, der Ursache auf den Grund zu
gehen?

Eine kaputtgegangene Installation schließe ich aus, da sich das Dokument
auf zwei Rechnern exakt gleich verhält. Zum Einsatz kommt LibreOffice
2.4.2 unter OpenSUSE Linux 12.1, falls das eine Rolle spielt.

Hallo Boris,

[reproduzierbarer Crash]

Gibt es eine erfolgversprechende Methode, der Ursache auf den Grund zu
gehen?

Vielleicht ist diese Mail[1] von Thorsten hilfreich?

[1] http://listarchives.libreoffice.org/de/discuss/msg11018.html

Gruß Nino

Hallo,

Vielleicht ist diese Mail[1] von Thorsten hilfreich?

nicht wirklich -die Arbeit mit einem Debugger ist mir fremd.

Ich habe jetzt eine andere Datei, die ebenfalls beim Löschen von
Absätzen crasht, doch jetzt habe ich eine Regelmäßigkeit entdeckt. Es
ist eine Briefvorlage, die ab Seite 2 eine andere Kopfzeile verwendet.
Das habe ich so realisiert, dass die Erste Seite das Seitenformat "erste
Seite" verwendet, mit dem Folgeformat "Standard". Dabei besitzt "erste
Seite" (u.a., versteht sich) nur eine Fußzeile, "Standard" jedoch Kopf-
und Fußzeile. Nach der ersten Seite findet also ein Formatwechsel statt.
Wenn ich nun auf der ersten Seite bspw. einfach nur leere Absätze
einfüge, kann ich diese unschädlich löschen, bis ich einmal eine zweite
Seite hatte. Der Cursor muss nicht einmal auf dieser zweiten Seite
positioniert gewesen sein; es reicht aus, dass sie existierte. Sobald
ich wieder so viele Absätze lösche, dass das Dokument nur noch eine
Seite umfasst, stürzt LO beim Speichern des Dokuments ab.

Da das mit einem blanken Dokument so nicht passiert, könnte man
einwenden, ich solle das Dokument halt neu anlegen. Dem halte ich aber
zweierlei entgegen: zum einen etwas rein praktisches: diese Vorlage ist
in jahrelangem Feintuning entwickelt worden, und es würde mich fast
lieber hinsetzen und künftig alle Briefe von Hand schreiben, als diese
Vorlage noch einmal aufzusetzen -vor allem, da nichts garantiert, dass
es dann funktioniert. Zum anderen habe ich noch etwas grundsätzliches
dagegen: ein Programm sollte grundsätzlich nicht abstürzen, und schon
gar nicht wiederholbar bei ganz normaler Bedienung -LO schon mal
überhaupt nicht. :wink:

Gibt es also einen anderen erfolgversprechenden Weg?

Einen Nachtrag habe ich noch:

Wenn ich nun auf der ersten Seite bspw. einfach nur leere Absätze
einfüge, kann ich diese unschädlich löschen, bis ich einmal eine zweite
Seite hatte. Der Cursor muss nicht einmal auf dieser zweiten Seite
positioniert gewesen sein; es reicht aus, dass sie existierte. Sobald
ich wieder so viele Absätze lösche, dass das Dokument nur noch eine
Seite umfasst, stürzt LO beim Speichern des Dokuments ab.

wenn ich das Dokument wieder fülle, so dass es wieder eine zweite Seite
hat, stürzt es beim Speichern nicht mehr ab. Kürze ich es wieder auf
eine Seite, crasht es. Das lässt sich auch bspw. durch Erhöhen und
Vermindern eines Absatzabstandes erreichen, dazu muss man kein Zeichen
oder Absatz löschen. Es hängt wohl nur daran, dass die zweite Seite
einmal existierte und dann nicht mehr.

Noch einen Nachtrag habe ich, und zwar habe ich im home-Verzeichnis
etliche Dateien Namens hs_err_pid*.log gefunden, die ich nach einigem
Probieren den LO-Abstürzen zuordnen konnte. Da in ihrem Kopf stets auf
die JRE Bezug genommen wird, habe ich einige andere Java-Versionen
ausprobiert: zwei OpenJDK und die aktuelle von Oracle, doch leider mit
demselben Ergebnis. Zur Gegenprüfung habe ich dann doch mal das
vorinstallierte Windows7 entjungfert und LO 3.5 darauf installiert:
damit tritt der Fehler nicht auf. Also liegt der Fehler entweder in
allen drei JRE-Versionen unter Linux oder im Zusammenspiel von LO mit
JRE, nehme ich an. Wem könnte ich denn da am zweckmäßigsten die
hs_err_pid*.log unter die Nase halten, damit der Fehler gefunden wird?