Seite 1 von 1

Re: Absturz bei Speichern

Verfasst: Mo, 22.03.2010 14:08
von hylli
Lösche mal das Benutzerverzeichnis und teste dann nochmal.

Hylli

Re: Absturz bei Speichern

Verfasst: Di, 23.03.2010 19:57
von Kruemel112
Moin
hast du schon probiert ob das Problem auch mit einem portablem OOo auftritt?
MfG

Re: Absturz bei Speichern

Verfasst: Di, 18.01.2011 22:47
von taraxacum
Hallo an alle,
Ich möchte auf diesen thread antworten, weil ich darauf hinweisen möchte, dass man sich als Admin mit dem Häkchen 'Open Office-Dialoge verwenden' evtl. Probleme einhandeln kann - bzw. ich bin dadurch auf ein solches gestoßen worden ...

unsere Situation:
Die 'eigenen Dateien' sind auf eine Freigabe 'User' auf dem Server 'Fileserver' und dort auf den Ordner %Username% umgebogen, und sind als Standartspeicherort für OOo-Dateien hinterlegt.
Die Netzwerkumgebung ist dem gemeinen User ausgeblendet, so dass er über den Pfad \\Fileserver\User\Lieschen Mueller\ NICHT auf seine eigenen Dateien zugreifen kann.

So, jetzt kommts:
Diese Einschränkungen gelten für den Windows Explorer.
Wenn der Haken 'OpenOfice-Dialoge verwenden' nicht gesetzt ist, werden die Dateizugriffsroutinen des Betriebssystems - Windows, also Explorer - genutzt, und die o.g Richtlinien gelten.
Wird der Haken allerdings gesetzt - man macht das gerne, weil der Dateizugriff dann deutlich schneller und sicherer ist -, dann werden die OO-internen Routinen benutzt, die die Dateien über ihre URL ansprechen.
Wenn ich dann eine Datei Öffnen will, in den 'eigenen Dateien' stehe, und die <BackSpace>-Taste oder das Symbol für 'übergeordneten Ordner' wähle, sehe ich alle quasi privaten Laufwerke.

Wenn dann nicht ABE (access based enumeration) aktiviert ist und die Berechtigungen nicht korrekt sitzen --- dann habe ich ein echtes Problem mit dem Datenschutz.
-------------
Ich habe das Häkchen 'OpenOffice - Dialoge verwenden' in unserer Umgebung aktiviert und achte per script täglich darauf, dass die Berechtigungen korrekt sind.

Re: Absturz bei Speichern

Verfasst: Mi, 19.01.2011 11:44
von pmoegenb
taraxacum hat geschrieben: unsere Situation:
Die 'eigenen Dateien' sind auf eine Freigabe 'User' auf dem Server 'Fileserver' und dort auf den Ordner %Username% umgebogen, und sind als Standartspeicherort für OOo-Dateien hinterlegt.
Die Netzwerkumgebung ist dem gemeinen User ausgeblendet, so dass er über den Pfad \\Fileserver\User\Lieschen Mueller\ NICHT auf seine eigenen Dateien zugreifen kann.
So, jetzt kommts:
Diese Einschränkungen gelten für den Windows Explorer.
Wenn der Haken 'OpenOfice-Dialoge verwenden' nicht gesetzt ist, werden die Dateizugriffsroutinen des Betriebssystems - Windows, also Explorer - genutzt, und die o.g Richtlinien gelten.
Wird der Haken allerdings gesetzt - man macht das gerne, weil der Dateizugriff dann deutlich schneller und sicherer ist -, dann werden die OO-internen Routinen benutzt, die die Dateien über ihre URL ansprechen.
Wenn ich dann eine Datei Öffnen will, in den 'eigenen Dateien' stehe, und die <BackSpace>-Taste oder das Symbol für 'übergeordneten Ordner' wähle, sehe ich alle quasi privaten Laufwerke.
Wenn dann nicht ABE (access based enumeration) aktiviert ist und die Berechtigungen nicht korrekt sitzen --- dann habe ich ein echtes Problem mit dem Datenschutz.
-------------
Ich habe das Häkchen 'OpenOffice - Dialoge verwenden' in unserer Umgebung aktiviert und achte per script täglich darauf, dass die Berechtigungen korrekt sind.
Hallo Tara,
die Netzwerkumgebung auszublenden heißt noch lange nicht, dass der Normaluser keinen Zugriff auf seine Daten hat. Er braucht nur im Windows-Explorer \\Fileserver\User\Lieschen Mueller\ einzugeben.

Re: Absturz bei Speichern

Verfasst: Mo, 27.07.2015 21:55
von SGibbi
Auf die Gefahr hin, hier einen uralten Thread hochzuholen muß ich meinen Senf dazugeben, auch wenn es etwas mehr geworden ist.

Der Fehler ist sehr unangenehm.

Zuerst verliert das (Writer) Dokument stillschweigend einen Teil seiner Bilder, schlußendlich stürzt die Sache beim Speichern ab. Nach dem Neustart wird zwar wiederhergestellt, doch was noch nicht gespeichert war, ist verloren.

Mitunter verfängt man sich sogar in einer Schleife, so wird beim Starten des Programms wieder hergestellt, doch spätestens beim Versuch eine Änderung zu speichern stürzt die Sache erneut ab. Andere Dateien gehen gar nicht mehr öffnen, denn die Office besteht darauf, wieder herzustellen.

Der Verlust der Bilder wird nicht angezeigt, gerade bei umfangreichen Dokumenten muß man das gesamte Dokument durchblättern. Der letzte Teil der Arbeit ist ohnehin verloren.

Wer nicht abhelfen kann, sollte wenigstens mit verlinkten Bildern arbeiten, denn die Links gehen nicht verloren. Daß man seine Bilder dann extern bereithalten muß, sollte selbstredend sein.

Eine bewährte „Erste Hilfe“ ist das Bereitstellen von mehr Arbeitsspeicher, sei es physikalisch mit RAM Riegeln oder durch optimieren der Software. Das kann durchaus durch „das Häkchen hier oder da“ sein, Hauptsache mehr Speicher, und die Sache läuft. Scheinbar. Falls man umfangreiche Dokumente mit vielen Grafiken hat, stundenlang daran arbeitet, und zwischendurch immer wieder mal abspeichert, bekommt man auch 8 GB an Arbeitsspeicher problemlos zum Überlaufen.

Ein Systemmonitor nebenbei, der den noch verfügbaren Speicher anzeigt, ist sinnvoll.

Es sieht also aus wie ein Fehler vom Betriebssystem, denn die Speicherverwaltung wird ja eigentlich vom Betriebssystem vergeben. Läßt man einen Systemmonitor mitlaufen, ergibt sich der folgende Verlauf: Nach dem Drücken von „Speichern“ läuft unten der „Blaue Balken“ durch, danach füllt sich der Arbeitsspeicher, offenbar werden große Teile vom Dokument gecashed. Nach jedem Speichern wird der Arbeitsspeicher etwas voller, und irgendwann reicht es nicht mehr aus, und die Sache stürzt beim Speichern ab.

Geprüft wurde mit folgender Konstellation:

Dokument 1: Ein eigenes Kochbuch, ca. 500 Seiten Umfang, reich bebildert
Dokument 2: Ein eigener Sammlungskatalog für Dampfradios, ca. 250 Seiten Umfang, viele großformatige Fotos

Austauschbare Hardware, vom 1 GHz Athlon und 384 MB RAM auf Elitegroup K7S5A bis zum Intel Core 2 Duo E 5700 und 8 GB RAM auf Asrock AS-G41MH sowie einige Zwischengrößen.

Austauschbare Software auf auswechselbaren Festplatten (im Festplattenrähmchen)

Open Office Org, bevorzugt Linux 3.1.1.4 # OOO310m21 Build 9319
Libre Office, bevorzugt Linux 3.3.1 # OOO330m19 Build 8

Linux openSuSE 11.2 32 Bit mit Kernel 2.6.31.5-0.1 wahlweise Default oder Desktop, „Tried & Tested“, nur sinnig erscheinende, vorgeprüfte Updates, bekannt stabil laufend
Linux openSuSE 11.2 LTS 32 Bit mit Kernel 2.6.31.14-0.8, wahlweise Default oder Desptop oder PAE, „alle Uptades bis zuletzt“, bekannt stabil laufend

Swap Space als eigene Linux Partition je 512 MB

Weiterhin standen für je eine Hardware ein Windows XP mit allen Updates sowie ein Windows 98 SE teils upgedated zum Testen mit zur Verfügung.

Java 1.5 (JRE 5) von FSF / Redhat (bei Linux)
Java 1.6.26 (JRE 6) von SUN (bei Linux)
Java 1.6.27 (JRE 6) von OpenJDK (bei Linux)

Meine Erkenntnis: Es ist ein Java Problem !

Die „Tried & Tested“ Installation mit OOo 3.1.1 und Java 1.5 ist zwar ein wenig veraltet, läuft aber steinstabil bei jeder meiner Hardware, sogar auf dem bekannt etwas problematischen K7S5 Board. Beim Speichern gibt sich folgende Beobachtung: Der Arbeitsspeicher wird zuerst komplett „zugerotzt“, danach hält es inne und die Sache swappt, falls erforderlich, auf Platte aus. Nach dem vollständigen Wiederaufbau der Arbeitsfläche wird mindestens ca. 150 MB freier Speicher bereitgestellt. Man kann nächtelang daran arbeiten, beliebig oft speichern, usw., selbst falls man beim Blättern viele Grafiken in den Cache holt, beruhigt sich die Sache, auch der Swap, nach einigen Minuten wieder, es bleibt stets genügend freier Speicher übrig.

Die „upgedatete“ Installation auf letztem Stand (naja, 2013) mit LiO 3.3.1 und Java 1.6.27 führt auch bei 8 GB Arbeitsspeicher und angepaßtem PAE Kernel (für die 8 GB RAM) sogar bei „kleineren“ Dokumenten nach längerer Arbeit zum Verlust von Bildern und schlußendlich zum Absturz wie beschrieben. Der Plattencache wird nicht angesprochen, zumindest nicht von der Office, und nach jedem Abspeichern wird ein wenig mehr von Arbeitsspeicher verbraucht, der auch nicht wieder freigegeben wird.

Der Fehler läßt sich bei beiden Installationen reproduzieren. Java 1.5 läuft leider nur auf der alten Installation, doch Java 1.6.26 läuft bei beiden stabil. Java 1.6.27 führt bei beiden Installationen zum benannten Fehler.

Draufgekommen bin ich über Fehlermeldungen „hs_err_pid (Nummer), welche (nur ?) unter Linux im „Dokumente“ Ordner erscheinen. Sie haben in etwa folgenden Inhalt (gekürzt):

#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0xb00b04fe, pid=2833, tid=2540989296
#
# JRE version: 6.0_27-b27
# Java VM: OpenJDK Client VM (20.0-b12 mixed mode linux-x86 )
# Derivative: IcedTea6 1.12.6
# Distribution: Dummy Product (i586), package suse-1.1-i386
# Problematic frame:
# C [configmgr.uno.so+0x424fe] std::vector<com::sun::star::uno::Any, std::allocator<com::sun::star::uno::Any> >::_M_insert_aux(__gnu_cxx::__normal_iterator<com::sun::star::uno::Any*, std::vector<com::sun::star::uno::Any, std::allocator<com::sun::star::uno::Any> > >, com::sun::star::uno::Any const&)+0x23f4
#

(gekürzt, mehr (viel mehr ;-) auf Anfrage)

Unter Linux lassen sich recht problemlos mehrere Java Varianten parallel installieren. Die Auswahl in der Office geht wie folgend:

→ Extras → Optionen → (Office) → Java → (etwas warten) → eine Auswählen

Für den Test einen Systemmonitor mitlaufen lassen, eher etwas weniger RAM und mehr an Swap, mehrere speicherintensive Bilder bereithalten, und prüfen, ob die Sache ggfs. swappt und nach dem Speichern wieder freier Arbeitsspeicher zur Verfügung steht. Oder ob es abstürzt. Ich empfehle bis auf Weiteres die Java Version 1.6.26, sie läuft bei mir bisher steinstabil. Zumindest solange der Swap nicht überläuft, aber das ist dann wirklich ein Speicherproblem.

Meine Anregung wäre, daß die Office selbst die jeweils installierte Java Version auf „Kompatibilität“ testet, und ggfs. eine passende Version mitgegeben wird. Wie auch immer man das mit Windows, das meines Wissens nur ein einziges systemweites Java kann, bewerkstelligen möge, sei mal dahingestellt, Linux ist da deutlich variabler. Solche Abstürze sind für den User mitunter sehr ärgerlich, aber auch für den Support, denn es liegt ja weder an der Ofiice noch am Betriebssystem.